ML14161A036
| ML14161A036 | |
| Person / Time | |
|---|---|
| Site: | MIT Nuclear Research Reactor |
| Issue date: | 07/10/2013 |
| From: | Mirion Technologies (MGPI H & B) |
| To: | Office of Nuclear Reactor Regulation |
| Shared Package | |
| ML14161A031 | List: |
| References | |
| MIT-01 SA-1330117 B50E, Rev. 1 | |
| Download: ML14161A036 (409) | |
Text
Non-popretiy vem 14 /T-0I MGPOH&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany This Is a non-proprietary version rrom which the proprietary Information has been removed according to 10 CFR 2.390 (trade secret). In this document the removed sections or proprietary information are indicated by two opening and two closing brackets as shown here: I I1 Introduction and overview for the set of qualification documents concerning the Digital Wide Range Channel DWK 250 intended to be installed at the Massachusetts Institute of Technology MIT Copyright 2013, Mirion Technologies (MGPI H&B) GmbH All dghts, including rights patent and registered-design rights, where applicable, reserved. Transmittal. reproduction, or utilization of this documert or disclosure of its contents without expressed authorization by the copyright holder are prohibited. Violators shall be held liable for damages Mirion Technndogies Landsberger Sir. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Munchen Fax: +49 (0)89 51513-169 Examin. of contents: EL Author: FTE / DSW I q- Doc-No. SA-1330117 B50E Formal release: C Page 1 of 13 Edition 112013-07-10 Mitteilung E-1310131 \FiWGPIMUCD0l MgpiGPr:ojekte\Techn Prokt-lnforrnation\PJKT )*duelN}07220 MT Oualficaton for
'd'FitE DW<MT2&Pdntroductionrlntroducfon
-Doc.SNo.WM330117 135E-to DWK 250 od1.docx
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT List of Revisions Revision Date Scope of Revision Section page 1 2013-07-10 First Revision all 1/2013-07-10 Page 2 of 13 Doc.No. SA-1330117 BSOE Edition:
Edition: 1/2013-07-10 Page 2 of 13 Doc.No. SA-1330117 B50E
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT Table of contents 1 Introduction .................................................................................................................................. 6
- 2. S co pe .......................................................................................................................................... 6 3, Project history ............................................................................................................................. 6
- 4. General information .................................................................................................................... 7
- 5. Development ...................... ...................................... 7 5.1. Hardware ............... .... ............. ............................................ 8 5.2. Software ............................... ..................... ..................... 9 6 Type-Tests ........................................................... 10 7 Applied Software Modifications ............................................................................................. 11 8 Application Specific Software Configuration ......................................................................... 12 9, Factory Acceptance Test ............. 1...........................
13 1C0. Site Acceptance Test ................................................................................................................ 13 111. Provided Documents and request to withhold documents or portions of them ...................... 13 Page 3 of 13 Doc.No. SA-1330117 B5OE Edition: If 2013-07-10 1/2013-07-10 Page 3 of 13 Doc.No. SA-1330117 B50E
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT References
[1] 1 01 TKV 23 Technical Information 5-0009 V10E ed4
[2] 2 01 TK 250 General protection and safety instructions 5-0125 A01 E ed2.pdf
[3] 2.02 Standard Data TK 250 25438 D09E ed5.PDF
[4] 3701 DWK 250 Technical Information 5-0106 D22E ed4.pdf
[5] 3.02 DWK 350 Short instruction 5-0106 A50E ed2.pdf
[6] 3.03 DWK 250 User Manual 5-8630 A70E edl .pdf
[7] 37.04 Supplement to information in the operation manual 5-0125 A02E edl .pdf
[8] 3.05 DWK 250 K01 2A Interface specification 023180 B70E edl .pdf
[9] 306 DWK 250 KI01 2A List of parameters 023180 L71 E ed2.pdf
[10] 3:07 DWK 250 Computer Interface Manual 5-0106 B93E ed2.pdf
[11] 4.01 NA 04 NA 06 Technical Information 5-0088 V1OE ed2.pdf
[12] 4..02 NA 33.3 Technical Information 5-0292 V1OE ed2.pdf
[13] 4.03 NB 22 Technical Information 5-0102 V10E ed2.pdf
[14] 4.04 NB 28.1 Technical Information 5-0209 VIOE ed3.pdf
[15] 4.05 NE 37.21 Technical Information 5-0261 V10E edl.pdf
[16] 4.06 NH 3x Technical Information 5-0140 VI1E edl.pdf
[17] 4.07 NI 21.2 Technical information 5-0235 VI 1E ed3.pdf
[18] 4..08 NI 21.21 Modification Description 5-8633 B50E edl .pdf
[19] 409 NK 21.2 Technical Information 5-0187 VI0E ed3.pdf
[20] 4710 NN 53.21 Technical Information 5-0336 V1OE edl.pdf
[21] 4:11 NR 31 Technical Information 5-0165 V10E ed2.pdf
[22] 4-12 NS 01 Technical Information 5-0044 V10E ed5.pdf
[23] 4-13 NT 61 Technical Information 5-0290 V10E ed2.pdf
[24] 4 14 NT 61.xx Variant Description 5-0290 V19E ed3.pdf
[25] 4715 NZ 12.2 Technical Information 5-0251 V10E edl.pdf
[26] 4-16 NZ 21.2x Technical information 5-0260 V1OE edl.pdf
[27] 501 DWK 250 circuit diagram 5-8630 G20-P20 MIT case edl.pdf
[28] 5_.02 DWK 250 circuit diagram 5-8631 G1 0-P30 MIT cabinet edl .pdf
[29] 6._01 Evidence of routine test of factory 25015-84 B5E ed8.pdf (30] 701 Test record routine test for DWK 250 0511.0.216.pdf
[31] 7i02 Test record routine test for DWK 250 0511.0.217.pdf
[32] 703 Test record routine test for DWK 250 0511.0.218.pdf
[33] 704 Test record routine test for DWK 250 0511.0.220.pdf
[34] 801 Mirion-Technologies KTA 1401 VGB-RWE AHA 02_2010 eng.pdf
[35] 802 Mirion-Technologies--MGPI-H-B--GmbHISO9001_en.pdf
[36] 9._01 List of type tested modules 25438 QI0 ed2.pdf
[37] 91P02 Explanation of SW article numbers 0348573 BI I E ed3.pdf
[38] 91_03 DWK 250 Functional Specification 5-0106 D1OE ed 2.pdf
[39] 92_01 DWK 250 Certificate No T-0101_91 15.01.1991 - D.pdf
[40] 92.02 DWK 250 Certificate No T-0101_91 15.01.1991 - E.pdf
[41] 92_03 Test program for the global test of the DWK 250 - 17.12.1990 - E.pdf
[42] 92_04 Test results of the global test of the DWK 250 February 1991 .pdf
[43] 92L05 Technical test report for the DWK 250 July 1991 -E.pdf
[44] 9301 Technical test report for the SW of the DWK 250 Aug. 1990 - E.pdf
[45] 93.02 Type test certificate for the SW of the DWK 250 No 1225068496.01 Aug. 1990 - D.pdf
[46] 93_03 Type test certificate for the SW of the DWK 250 No 1225068496-01 Aug. 1990- E.pdf
[47] 93_04 TUV Certificate for DWK 250 K0005 Doc.-No. 27-97-YQ-AOI E.pdf
[48] 9401 DWK 250 K01 2A Configuration specification 023180 B71 E edl - E.pdf
[49] 9402 DWK 250 K012A Interface specification 023180 B70E edl - E.pdf
[50] 94._03 DWK 250 K01 2A List of parameters 023180 L71 E ed2 - E.pdf
[51] 94..04 DWK 250 K012A Verification plan and protocol 023180 F70E ed 1 - E.pdf
[52] 94-05 DWK 250 K01 2A Verification plan and protocol 023180 F70E edl - Template - E.pdf
[53] 9501 Quality assurance in the Software Development - Manual - 0348548E - ed l.pdf
[54] 9502 Software Quality Assurance Plan (SOAP) - 0348664 A60E - ed4.pdf Edition: 1/2013-07-10 Page 4 of 13 Doc.No. SA-1330117 B50E
Non-proprietary version Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT
[55] 95_03 Software Verification and Validation Plan (SWP) - 0348666 A60E - ed2.pdf
[56] 95_04 Software Configuration Management Plan (SCMP) - 0348665 A60E - ed2.pdf
[57] 9505 Software Coding Rules 0348662 A60E - ed2.pdf
[58] 961_01 NB 28.1 NT 31.1 NS 01.12 NK21.2 Pr~fzeugnis.pdf
[59] 96102 NZ 12.11 NK 21.2 NB 28.1 NT 31.1 NS 01.12 Praktische Typpr(fung.pdf
[60] 961_03 NZ 12.11 NK 21.2 Stellungnahme zu den Anderungen 945-K 73001-95.pdf
.[61] 961-04 NK 21 Test Certificate TUV Rheinland - E - .pdf
[62] 962_01 NZ 12.21 Technischer Prafbericht Februar 2008.pdf
[63] 962U02 NZ 12.21 Certificate Nr. ETS1_NZ12.21_1 Februar 2008.pdf
[64] 962903 NZ 12.21 Technischer PrQfbericht Nr. NZ 1221 082008 Februar 2008.pdf
[65] 962_04 NZ 12.21 Theoretische PrOfung.pdf
[66] 962_05 NZ 12.21 Grenzbelastungsanalyse.pdf
[67] 962_06 NZ 12.21 Pr(fanweisung Praktische Pr0fung.pdf
[68] 962_07 NZ 12.21 Praktische Pr~fung.pdf
[69] 963A,_01 Zertifikat NO TK250 Baugruppen 042007 Anhang l.pdf
[70] 963A,02 TK 250 Baugruppen Technischer Prifbericht.pdf
[71] 963A_03 TK 250 Baugruppen Priffprotokolle Anhang 2.pdf
[72] 963B_01 NZ 21.21_NZ 21.22 Technischer Pr~fbericht KTA 3505.pdf
[73] 963B102 NZ 21.21_NZ 21.22 Certificate Nr. NZ21.21_22 062006.pdf
[74] 963B_.03 NZ 21.21_NZ 21.22 Technischer PrQfbericht Protokolle Anhang 2.pdf
[75] 10_01 Certificate of Acceptance with attachments 14-16.12.2011 .pdf
[76] 11_01 MIT SAT Protocol No. 023180 Date 25-02-2012.PDF
[77] Affidavit Page 5 of 13 Doc.No. SA-1330117 BSOE Edition: 11/2013-07-10
/ 2013-07-10 Page 5 of 13 Doc.No. SA-1330117 B50E
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT
- 1. Introduction In the year 2011 the Massachusetts Institute of Technology (MIT) purchased three Digital Wide Range Channels (DWK 250) from Mirion Technolgies (MGPI H&B), Munich / Germany1 .
In order to support the Technical Report for US NRC approval of these DWK 250 wide-range neutron flux channels, Mirion Technologies has established a set of related qualification documents.
The purpose of this document is to provide an introduction and overview for this set of qualification documents.
- 2. Scope This document is established by Mirion Technologies. It applies to the Digital Wide Range Channels DWK 250, that have been delivered to the MIT in 2011 and to the related set of qualification documents.
- 3. Project history The following table provides an overview of the main DWK 250 milestones and of the project history:
Date Milestones 1988 - 1990 Development of the Digital Wide Range Channel DWK 250 Type test of the DWK 250:
- The Type Test of the channels hardware and of the channel in 1989 - 1991 general was performed by the TUV Rheinland (in 1989- 1991)
- The type test of the channels software was performed by the TOV Nord (1989 - 1990) 1995 Revision C of the NK 21 - software was release by Mirion Technologies.
For the NPP KrUmmel / Germany a minor modification was applied to the 1997 software of the DWK 250 Software in 1997. This modification was verified by TUV Nord.
Since 1991 The Digital Wide Range Channel is used by different NPPs and Research Reactors. It has gained a very good operational experience.
2011-03-08 Purchase Order from MIT Sept. - Nov. 2011 Mirion establishes a MIT specific software configuration for the DWK 250 December 2011 Factory Acceptance Test for MIT February 2012 Site Acceptance Test at MIT
'Mirion Technologies also provided MIT a 4 th unit to be used on consignment for three years.
Edition: 1/2013-07-10 Page 6 of 13 Doc.No. SA-1330117 B50E
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT
- 4. General information In Nuclear Power Plants and Research Reactors the Digital Wide-Range Channel DWK 250 measures the neutron flux density, beginning from start-up level up to the power range. In these applications fission chambers are used as neutron flux detectors. With its preamplifier and signal preprocessing boards the channel is designed to capture the pulse mode and fluctuation mode signals (Campbell-Mode), that are provided by the installed fission chamber. Based on its pulse and Campbell mode signal processing and depending on the fission chambers properties, the Digital Wide Range Channel is able to provide an overall measuring range of 10 to 12 decades.
The Digital Wide Range Channel DWK 250 is a member of the TK 250 product family. When it was introduced into the market in 1991, it replaced preceding analogue channels from Hartmann &
Braun's TK 240 product family 2.
Further technical details about the Digital Wide Range Channel in general are provided by the following documents:
0 Technical Information (see [41) 0 User manual (see [6D 0 Computer interface manual (see [10])
- 6. Development The Digital Wide Range Channel DWK 250 was developed in the years from 1988 to 1990. A general overview of the channels structure is given in Fig. 1.
Fig. 1: General overview of the DWK 250 structure The functional specification for the DWK 250 is given in document [38].
2 At that time the Mirion dependency in Munich was part of Mannesmann, Hartmann&Braun, H&B. Thus the related documents from this period show this company name in their headers.
Edition: 1/2013-07-10 Page 7 of 13 Doc.No. SA-1330117 B50E
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT 6.1. Hardware The DWK 250 is a modular 19" system. The front view of the channel is shown in Fig. 2. Its circuit diagram is shown in [27] and [28]. The hardware modules of the DWK 250 are listed in chapter 2.3 of [4].
S F -1 digial wide M________
32.51..
09
ýWl W$72 13 range channel IM.IWI 17 21 1.1
.1 1111.21 1111.11 125 12 DWK 250 I
1333
~
7 41 4S 1(01 2.4B21~3)N50V 4 F5s NMC -101L511-¶6¶ 63 73 i.5I 3,121 78 J
0 11Y 0
F-10C.F-F1 E - F- I-1i I R, 0-IN..3F W 5 Fig.~~~~~0 oh v;Fotve Fig. 2: Front view of the OWK 250 The modular 19" system of the DWK 250 enables Mirion to accommodate the channel to certain customer requirements. For instance the isolation amplifiers for the analog output signals can be chosen according to the customers' requirements concerning the characteristic of the analog output signals, e.g.: 0...1OV, 2... 1V, 0...20mA, 4... 20mA.
The electronic modules that build the DWK 250, are type tested. Chapter 4 of the document [36]
provides a list of the type tested modules.
For each electronic module:
> a set of type test documents has been established
> a type test has been performed by/with a TOV organisation
> a TUV test report and test certificate is available
> a document called "Technical Information" provides key information about the module (see documents [11] to [26])
The set of qualification documents, which Mirion provides to the MIT and the US NRC at this stage of the project, is a subset of the DVVK 250 documentation, because
> of the total amount of documentation for the electronic modules
> some of the type tests for the electronic modules were carried out in German and are not available in English Thus Mirions selection of the provided qualification documents concerning the electronic modules focuses on the processor boards of the DWK 250. In order to support the qualification process, Mirion proposes that the US NRC performs audits at the Munich dependency of Mirion, to review the complete set of qualification documents for all electronic modules. However upon request Mirion will translate and provide requested qualification documents.
In addition to the type test of the individual electronic modules a type test of the DWK 250 in general has been performed (see chapter 6).
Doc.No. SA-1330117 B50E Edition: 1 I/ 2013-07-10 1 2013-07-10 Page 8 Page of 13 8 of 13 Doc.No. SA-1330117 B50E
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT 5.2. Software The following electronic modules of the DWK 250 are processor boards (see yellow marked boards in Fig. 1):
> NZ 12.21 Main processor
> NZ 21.21 Input / output processor
> NK 21.23 Serial data interface These boards are equipped with (( )) microcontrollers. The software of these boards has been developed in the years 1988 to 1990. In this process the following tools have been used:
>' Intel ASM51 Assembler (for NZ 12.21, NZ 21.21 and NK 21.23)
> Intel PL/M 51 Compiler (for NZ 12.21 and NK 21.23)
The software identification numbers of the resulting software from 1991 are:
> NZ 12.21: 3110 347 B
> NZ 21.21: 3110 350 B
> NK 21.23: 3110342 B A type test has been performed for this DWK 250 software and for the channel in general (see chapter 6).
In 1997 a minor modification (i.e. improvement) of the DWK 250 software was implemented by Mirion Technologies and tested by the TOV Nord (see chapter 7 for further details).
The software of the DWK 250 can be adapted to customer requirements, by applying specific configuration parameter settings to predefined constants within the software. These configuration parameters are stored in the EPROMS of the processor boards (NZ 21, NZ 12, NK 21) and thus can only be modified by the manufacturer. Further details about the software configuration process for the Digital Wide Range Channels that have been delivered to the MIT are given in chapter 8.
In the years 1988 to 1990 the software development process was carried out according to the manual "Quality Assurance in the Software Development" (see document [53]). In 2011 the application specific software configuration of the DWK 250 was carried out according to the current SW-QA documents: SQAP, SVVP, SCMP and Coding Rules (see [54], [55], [56], [57]).
Edition: 1/2013-07-10 Page 9 of 13 Doc.No. SA-1330117 B5OE
Non-propietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT
- 6. Type-Tests The type test of the Digital Wide Range Channel was carried out by the following TUV organizations:
- TUV Nord, Hamburg Type test of the DWK 250 Software
- TUV Rheinland, Kdln Type test of the DWK 250 Hardware and Channel in general It was subdivided into 4 phases:
- 1. Coordination between Mirion (Hartmann & Braun) and the different TUV organisations (TUV Nord, TOV Rheinland, TUV Sod). In this initial phase the TUV Sod (located in Munich) was involved (consulted), in order to make sure that the Type Test results would be accepted by all TOV Organisations in Germany.
I1. Development of the Software and Hardware of the DWK 250.
At the end of this phase a reference channel was build and sent to the TUV Organisations (TOV Rheinland, TUV Nord). Additionally the complete source code of the DWK 250 software, the ERPOM image files for the processor boards and the related software documentation files have been sent to the TUV Nord.
Ill. In this phase the TOV Rheinland performed the theoretical and practical tests for the individual plug in modules and the DWK 250, while the TOV Nord performed tests and analyses for the software of the DWK 250. For test purposes a Digital Wide Range Channel was installed in the 4h' redundancy of the German NPP Wurgassen for more than one year.
IV. Global test At the end of the type test a global test was performed These Type Tests were carried out according to
> KTA 3501 6/85
> KTA 3503 11/86
> KTA 3505 11/84
> DIN VVDE 0801 01/90 The main type test documents and certificates from the TUV are:
> [40] DWK 250 Certificate TUV Rheinland
> [41] Test program for the global test of the DWK 250 TOV Rheinland
> [42] Test results for the global test of the DWK 250 TOV Rheinland
> [43] Technical test report for the DWK 250 TOV Rheinland
> [44] Technical test report for the SW of the DWK 250 TUV Nord
> [46] Certificate for the SW of the DWK 250 TOV Nord 13 Doc.No. SA-1330117 B5OE Edition: 11/2013-07-10
/ 2013-07-10 Page lOof Page 10 of 13 Doc.No. SA-1330117 B50E
Non-proprietary version Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT
- 7. Applied Software Modifications In the year 1997, a minor modification (improvement) was applied to the software of the DWK 250.
Through this modification the scale end value of the counting rate became configurable for analogue output #AA4. This modification only affects the scaling of the output signal for analogue output number 4 and does not affect the channels signal processing itself. This modification has been verified by the TOV Nord (see [47]).
The Software identification numbers of the modified software are:
NZ21: 3110 490 A Configuration: K0005 NZ12: 3110 489 A Configuration: KO005 The modified software is derived from the initial DWK 250 software from 1991:.
Software identification number Processor Board Software from 1991 Modified software from 1997 NZ 12.21 3110 347 B 3110 489 A NZ 21.21 3110 350 B 3110 490 A In 1995 a new revision of the software for the NK 21 processor board was established by Mirion Technologies (H&B). With this new revision the following improvements for the NK 21 board have been introduced:
> Support for RS485 bus systems
> Watchdog
> CRC checksum for program memory (EPROM)
> Monitoring for S-Bus malfunction
> Increased baud rate 19 200 baud The modified NK 21 software (rev. C) has been type tested by the TUV Rheinland (see [61D.
Page 11 of 13 Doc.No. SA-1330117 B5OE Edition: 11/2013-07-10
/ 2013-07-10 Page 11 of 13 Doc.No. SA-1330117 B50E
Non-proprietary version Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT
- 8. Application Specific Software Configuration The software of the DWK 250 can be adapted to customer requirements, by applying specific configuration parameter settings to predefined constants within the software. These configuration parameters are stored in the EPROMs of the processor boards (NZ 21, NZ 12, NK 21) and thus can only be modified by the manufacturer.
In 2011 an MIT specific software configuration setup for the DWK 250 was established by Mirion Technologies. The ID number for this SW configuration is: KO12A. Since this configuration setup also includes a translation of the channels user interface from German to English, a new software identification number was assigned to the software of the NZ 12 processor board (which contains the HMI hardware): 3110 519 A.
In the frame of this software configuration process the following documents have been established by Mirion Technologies:
> [48] DWK 250 K012A Configuration specification
> [49] DWK 250 K012A Interface specification
> [50] DWK 250 K012A List of Parameters
> [51] DWK 250 K012A Verification plan and protocol
> [52] DWK 250 KO12A Verification plan and protocol - Template -
The following table provides an overview of the software identifications numbers:
Software identification number Processor Board Initial software Modified software Software for MIT from 1991 from 1997 / 1995 in 2011 NZ 12.21 3110 347 B 3110 489 A 3110 519 A NZ 21.21 3110 350 B 3110 490 A 3110 490 A NK 21.23 3110 342 B 3110 342 C 3110 342 C For the software of the Digital Wide Range Channel DWK 250 there is a distinction between the software itself and the software, which is stored on specific media (i.e. different types of EPROMs).
Accordingly different identification numbers are assigned to the original software and the software that is stored on certain EPROM types (see document [37] for further explanations concerning software article numbers).
In the past years it became necessary to establish new editions of a few electronic modules, because some electronic components (IC's, etc.), which have been part of these electronic modules, have been discontinued by their manufactures. So for the NZ 12 and NZ 21 board new editions have been established, which led to the introduction of new EPROM types on these board (( )) for NZ 21.21 and f[ )) for NZ 12.21). To distinguish the DWK 250 software stored on these new EPROM types from the software stored on the previous EPROM types, unique software identification numbers have been assigned to the software itself (see table above) and the software that is stored on these EPROM types (see document [37]).
of 13 Doc.No. SA-1330117 BSOE Edition: 1/2013-07-10 1/2013-07-10 Page 12 Page 12 of 13 Doc.No. SA-1330117 B50E
Non-proprietaryversion Introduction and Overview for the Qualification Documents concerning the Digital Wide Range Channel DWK 250 at the MIT
- 9. Factory Acceptance Test The factory acceptance test for the Digital Wide Range Channels DWK 250 took place in Munich on the 14th to 16th December 2011 (see FAT protocol in [75D.
10.Site Acceptance Test The site acceptance test for the Digital Wide Range Channels DVVK 250 was carried out at the MIT, Cambridge, USA, on 02/24/2012 (see SAT protocol in [76D.
11.Provided Documents and request to withhold documents or portions of them Mirion Technologies requests to withhold the provided qualification documents or portions of them from public disclosure. An affidavit and its annex (see [77D provide detailed information about this request.
According to US NRC 10 CFR 2.390 (Public inspections, exemptions, requests for withholding)
Mirion Technologies has established two sets of qualification documents for the DWK 250:
- One set of proprietary documents
- One set of non-proprietary documents Edition: 1/2013-07-10 Page 13 of 13 Doc.No. SA-1330117 B50E
144 /7-- OQ_
Non-proprietary Version MGPIH&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement - Munich, Germany This is a non-proprietary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( ]
Neutron-Flux Monitoring Channels TK 250 DWK 250 Digital Wide Range Channel Specification / Technical Information Page 1 of 17 Doc. -No. 5-0106 D22E Edition 01.06.2010 Edition 44// 01.06.2010 Page 1 of 17 Doe.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel Table of contents
- 1. Description ......................................................................................................................................... 3 1.1 Features ........................................................................................................................................ 3 1.2 Detector and preamplifier .................................................................................................... 4 1.3 Signal processing ............................................................ .......................... 5
- 2. Measurement setup com ponents ................................................................................................. 6 2.1 Suitable detectors ......................................................................................................................... 6 2.2 Setup of the signal channel ..................................................................................................... 6 2.3 Electronic modules ....................................................................................................................... 7 2.4 Software ....................................................................................................................................... 8
- 3. Operation ........................................................................................................................................... 9
- 4. System integration ........................................................................................................................... 10
- 5. Safety standards and qualification .............................................................................................. 11
- 6. Technica l data .................................................................................................................................. 12 6.1 TKV 23.21 pream plifier ............................................................................................................... 12 6.2 Input signals to the central electronics unit .......................................................................... 12 6.3 Signal processing ....................................................................................................................... 13 6.4 O utput signals ............................................................................................................................ 13 6.5 Digital characteristics and interfaces ...................................................................................... 14 6.6 Power supply .............................................................................................................................. 14 6.7 Ambient conditions ..................................................................................................................... 15 6.8 Mechanica l data ......................................................................................................................... 15 Appendix A.1 DW K 250 schematic diagram ................................................................................... 16 Appendix A.2 List of technical documentation ............................................................................... 17 Edition 4/01.06.2010 Page 2 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel
- 1. Description 1.1 Features The Digital Wide-Range Channel DWK 250 measures the neutron flux density, beginning from start-up level up to the power range*. The combination of the traditional pulse and intermediate range channels will drastically reduce the space requirements in the electronic rack, and only one detector, one penetration and one preamplifier is needed together with the DWK 250. Additionally, the number of cables and the effort for periodical testing can be reduced.
The Digital Wide-Range Channel has the following features:
- Neutron-flux monitoring channel covering both start-up and intermediate ranges
- Only one detector for the whole range: a wide range fission chamber, in-core or ex-core
" Ten-decades to twelve-decades dynamic range*
- Acquisition of detector pulses in the pulse range
- Acquisition of the AC detector current in the intermediate range with lockable auto-ranging
- Processing of both input signals with linear analog outputs for the reactor protection system
- Generation of the wide-range signal by merging pulse signal and AC signal
- Signal smoothing employs a programmable filtering curve
- Calibration of the wide range signal to neutron flux or power units (nv, %Pn)
- Calculation of the relative neutron flux change rate (reciprocal of the reactor period)
- Two analog outputs, user-defined, linear or logarithmic, e.g. for indicators or recorders
" Up to 16 adjustable alarms
- Remote controlled test generators in all input modules, including preamplifier
- Continuous functional monitoring of internal operations
- Numerical parameter settings, stored in non-volatile memory with lockable access
- Serial interface for data and parameter exchange with an external computer
- depending on detector data.
Page 3 of 17 Doc.-No. 5-0106 D22E Edition 44/01.06.2010 Edition / 01.06.2010 Page 3 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel 1.2 Detector and preamplifier In a fission chamber, nuclear fissions are triggered by the neutrons which are to be measured. The fission products generate pulse discharges in the detector. At high neutron flux densities, this pulse stream integrates to a direct current that has a fluctuating current superimposed on it due to the random nature of the nuclear events.
At the high operating temperatures involved, the electrical isolation of the detector and interconnecting cable will be degraded and a leakage current will be superimposed on the detector current. Thus the DC detector current generated at low reactor power is no direct value for the neutron flux density.
However, Campbell's formula for stochastic signals states that the mean-square value of the alternating current is an accurate measure of the direct current generated by the neutrons. The necessary squaring also yields a highly effective discrimination smaller pulses caused by gamma radiation.
((
1]
detector preamplifier main electronic rack I- .° K
k aneJog signal processing digital signal processing )
Signal paths within the DWK 250 Page 4 of 17 Doc.-No. 5-0106 D22E Edition 44101062010 Edilion / 01.06.2010 Page 4 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel 1.3 Signal processing In the central electronics unit both preamplifier output signals are electronically conditioned, digitized, and finally numerically merged into the wide-range signal.
((:
))
The pulse signal and the AC-signal for controlling the reactor protection system may be decoupled in order to yield linear analog signals and alarm signals, even before they are processed by the overlap algorithm. Both final results (neutron flux and relative change rate), along with all intermediate results, may be monitored by up to 16 adjustable low or high alarms and routed to two analog outputs, linearly or logarithmically scaled with adjustable settings.
Detector voltage and internal operating voltages will be monitored for compliance with adjustable tolerances. The microprocessor and its program, data and parameter memories will be continuously monitored in the background during the cycle of normal operation.
Page 5 of 17 Doc.-No. 5-0106 D22E Edition 4/01.06.2010 4 / 01.06.2010 Page 5 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel
- 2. Measurement setup components 2.1 Suitable detectors Suitable detectors for the use with the Digital Wide-Range Channel DWK 250 are wide-range fission chambers designed for in-core or ex-core application. The (mineral-insulated) interconnecting cable should have a defined impedance, e.g., 50 Ohms.
Model No. Features Manufacturer VVSK 61 Miniature in-core detector Siemens/Areva (Germany)
CFUG 08 High sensitivity, LOCA-proof, ex-core Photonis (France)
NY-10382 Wide-range ex-core fission chamber Mirion-IST (USA) 2.2 Setup of the signal channel The preamplifier is installed in an outer housing suitable for use at the installation site. The preamplifier's input and output impedances shall be adapted to the impedances of the coaxial cable employed. The distance between the detector and preamplifier will thus be limited only by noise on the cable and cable attenuation, and not by cable capacitance, and may be up to 100 m and even more. The distance between the preamplifier and the central electronics unit may be several hundred meters, and is limited by cable attenuation only.
The central electronic unit's hardware and software are modularly designed and combined with components of the TK 250 Digital Signal Processing System. The central unit's plug-in modules are installed in a 19" rack that is preferably accommodated in an electronics cubicle, but also may be accommodated in wall-mount or desktop housings. The high-voltage power supply for powering the detector and the type and number of output-signal interfaces are selected on customers demand.
DVVK 250: Digital Mde Range Channel for the Start-up and Intermediate Range "M NS I(21 N821 NR31 NT31 8301 810 Wei I8 NN443
- . =
O
- 1.2340-03 U
P/Pn n
AA "f
A 0
1 __
II Ia a a I -
__________ a a a a a a a 19 Electronics assembly of the DWK 250 Page 6 of 17 Doc-No. 5-0106 D22E Edition 44/01.06.2010 Edition / 01.06.2010 Page 6 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel 2.3 Electronic modules Depending on type of detector and configuration of the signal processing channel the following preamplifiers are used:
1 TKV 23.11 ((
or TKV 23.21 The following 19" plug-in modules may be part of the central electronics unit:
1 NH 36.51 or NH 42.11 1 NA33.11/12 1 NB22.11 1 NI 21.21 1 NZ 21.22 1 NZ 12.21 1 or 2 NB21.21 1 NS 01.12 1 or more NT 31.12 or NT 31.14 or NT 61.41/.51 1 NN 43.12 or NN 53.12 The following modules may also be installed, if required by the application involved:
1 NE 31.11 1 NR 31.11 I or more NB28.11 1 or more NA 04/06 1 NK 21.21 1 NY 31.xx 1 NN 45.11 Page 7 of 17 Doc. -No. 5-0106 D22E Edition 01.06.2010 Edition 441/ 01.06.2010 Page 7 of 1.7 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel 2.4 Software The Digital Wide-Range Channel incorporates up to three different microprocessor modules employed as central signal-processing units that exchange the necessary data via a serial bus (S-bus). The functions of the monitoring system are determined by the software, which is stored in EPROM's, i.e., cannot be subsequently altered, situated on the three microprocessor modules:
((
11 Comparison of 1/0-processor and central processor:
1]
Software routines which are closely related to safety are collectively handled by the NZ 21 1/0-processor. The hardware and software of the NZ 21 and NZ 12 processor modules are interlinked by the internal serial bus (S-bus) only and have no means for mutual access to program and data memories. The NZ 21 1/0-processor will remain operational even if the NZ 12 central processor should fail.
These measures decrease the number of hardware and software modules on the signal paths that are closely involved to highest safety-related relevance. They improve the reliability and allow using various testing tools for certifying the software packages used on the NZ 21 and NZ 12 modules.
Page 8 of 17 Doc. -No. 5-0106 D22E Edition 4/01.06.2010 Edition 4 / 01.06.2010 Page 8 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel
- 3. Operation The DWK 250 Digital Wide-Range Channel may be either manually operated from its front panel or remote controlled by an external computer via its serial interface. The operations that may be controlled are:
- Display of measured values
" Monitoring of status information
- Display and editing of parameter settings
" Initiating test procedures All operations will run without interrupting measuring and signal-processing operations, and, except for the operations of parameter settings and test procedures, will not affect them.
Changing the values of parameters and initiating testing procedures, both may be locked by using key switches, intervene in the signal path immediately after their activation and will thus affect output signals.
Manually initiated operations are arranged in a menu table and controlled by eight function keys. A two-line liquid-crystal display with 16 alphanumeric characters per line visualizes the measured values and dialog prompts and responses. Selected measured values and values of parameters are displayed, complete with their names, numerical values, and units.
The values of all digital signal-processing parameters, except preconfigured trip alarms and the scaling of the reactor-protection path, may be numerically adjusted and are protected against unauthorized alteration and voltage outages.
A number of 16 different high and low alarms having adjustable thresholds and hystereses may be selected for any, or all, existing measured values. Several alarm outputs may be combined on one binary output using a logical OR-function. Malfunctions, test reports, and violations of alarms will be reported by the binary signal module with isolated relay contacts.
The TKV 23 preamplifier and NI 21 and NA 33 input modules included in the central electronics unit are equipped with test generators that may be activated via the operating menu using the function keys. Analog and binary output signals may also be simulated via the operating menu and function keys in order to monitor the output modules and the peripherals interconnected to them.
Major hardware components, e.g., microprocessors, program memories, detector voltage, and the internal supply voltages, program execution, and internal data-transmission lines, are continuously monitored, in parallel with the performance of the normal signal-processing functions and user-initiated operations.
Page 9 of 17 Doc-No. 5-0106 D22E Edition 44/01.06.2010
/ 01.06.2010 Page 9 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel
- 4. System integration The Digital Wide-Range Channel allows continuous acquisition of the neutron flux density and calculation of the neutron-flux change rate over a dynamic range of more than ten decades, without need for external intervention, due to combining and merging of the startup and intermediate ranges and autoranging. In addition to clearly arranged information for the reactor operator, the channel provides signals for the reactor protection system that are transmitted on a seperated signal path, which has been specially optimized in relation to simplicity and reliability. Its autoranging feature, with integrated time control in order to delay shifting to another range and allows intentionally disabling or delaying reactor startup, is a totally adequate substitute for the former manual selection of measurement ranges, and is thus capable of relieving reactor operators of the need for performing tasks that would otherwise be necessary.
However, the wide-range digital channel also allows adaptations to suit a wide variety of existing or desired display and operating concepts:
- The expander amplifier on the NA 33 module generates the traditional logarithmic startup signal (a count rate of, e.g., 0.1 - 5e5 cps), either indirectly, by deriving it from the wide-range signal, or directly, by programming the amplifier.
- The linear multirange signal in the intermediate range ("sawtooth", 0- 40/125 %) and the measurement range (obtained from NR 31) are both available.
" The traditional manual switching to a higher measurement range may be simulated using its autoranging lockout, i.e., by enabling measurement-range switching by pressing a key.
- Autoranging may be supplemented by inserting selected, manually enabled, holdpoints to defined measurement ranges.
- Automatic switching to a lower measurement range may be locked out for testing purposes.
Page 10 of 17 Doc-No. 5-01 06 D22E Edition 01.06.2010 Edition 44 // 01.06.2010 Page 10 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel
- 5. Safety standards and qualification The Digital Wde-Range Channel has been designed in accordance with all generally applicable safety regulations. The following standard particularly applies to electrical safety:
- DIN-EN (IEC) 61010-1 2001 (VDE 0411-1) "Safety regulations for electrical measurement and control equipment" The equipment has been designed and manufactured in compliance with the following German regulations:
- KTA 3501 Reactor protection system and monitoring equipment of the safety system
- KTA 3502 Accident measuring systems
- KTA 3505 Type-testing of measuring sensors and transducers of the safety-related instrumentation and control system
" KTA 3507 Factory tests ... for the instrumentation and controls of the safety system
" KTA 1401 General requirements regarding quality assurance
" Quality management manual, Mirion Technologies (MGPI H&B) GmbH, Munich The Digital Wide-Range Channel has been subjected to type testing in accordance with the stipulations of guidelines KTA 3501/3505:
Component Model No. Assembly Kit Testing Agency Date Report No.
Entire channel DWK 250 5-0106 TUV-Rheinland Jan. 15,1991 T-0101/91 Software DWK250 5-0106 TOV-Nord. Aug. 16,1990 1225068496/01 Preamplifier TKV23 5-0009 TOV-Rheinland Nov. 11, 1987 KVWVV-1101/87 The Digital Wide-Range Channel has a very good operational experience in nuclear power plants with both boiling-water and pressurized-water reactors.
The ,,list of type-tested components" with the doc.-no. 25438-QIO shows the updated status of the type tests.
Page 11 of 17 Doc-No. 5-0106 D22E Edition 44/01.06.2010
/ 01.06.2010 Page 11 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel
- 6. Technical data Some of the following characterizations are extracts or abbreviations of the specifications of the module used in the DWK 250 Digital Wide-Range Channel.
6.1 TKV 23.21 preamplifier Input impedance 50 0 (75 0 is optionally available)
Pulse gain ((
Pulse output AC-amplification AC-bandwidth Output impedance, both paths Remote test generator Detector voltage (supplied by the central electronics unit) 6.2 Input signals to the central electronics unit NI 21 pulse discriminator Pulse repetition rate Pulse width Discriminator threshold Input impedance Test generator NA 33 AC-input Input voltage Input resistance Test generator NB 21 isolated logic inputs e.g., for enabling operation and range switching 24-V logic inputs ((
High-level Low-level Input resistance Electrical isolation Active contact call-up Call-up voltage ]
Electrical isolation Edition 4 / 01.06.2010 Page 12 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel 6.3 Signal processing Signal filtering:
Filter type Min./rnax. time constant variable time constant Response times:
Lin. count rate for RPS Lin. AC-signal Wide range signals Signal-processing errors Digital signal processing Discriminator dead-time error E.g., for td = 40 ns at n = le5 cps NZ 21 analog inputs NZ 21 analog outputs NZ 21 logarithmic count rate output and change rate output NTXX output isolation amplifier NZ 12 digital display Errors El and E2 are referred to measured values. Errors E31, E32, E33, and E34 are referred to the full scale values of the respective electrical signal involved, e.g., 10 V or 20 mA. Digital compensation for discriminator dead time that will eliminate error E21 may be used in conjunction with digital compensation for detector dead time.
6.4 Output signals Analog outputs isolated, buffered via NT 31/61 Output current 0/4 mA to 20 mA Load ((
Rise time Electrical isolation Binary outputs (relay contacts)
Contact type Switching parameter Switching voltage Switching current Switching power Electrical isolation (test voltage)
Page 13 of 17 Doc.-No. 5-0106 D22E 4 // 01.06.2010 Edition 4 Edition 01.06.2010 Page 1.3of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel 6.5 Digital characteristics and interfaces Microprocessors ((
Clock frequency Program memory Parameter memory Internal serial bus (S-bus)
External asynchronous data interfaces Electrical isolation 6.6 Power supply DC power supply Nominal input voltage / current Input voltage range (for modules)
Input peak voltage Voltage dropouts Voltage ripple (peak-peak)
Electrical isolation AC power supply Input voltage and frequency Power consumption Input peak voltage Voltage dropouts Electrical isolation Internal supply voltages Logic-circuit supply voltage Analog-circuit supply voltages Detector voltages NH36 high-voltage module NH 32 high-voltage module NH 42 high-voltage module Page 14 of 17 Doc-No. 5-0106 D22E Edition 44/01.06.2010 Edition / 01.06.2010 Page 14 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel 6.7 Ambient conditions Ambient temperatures ((
Open rack Wall mounting or table housing Storage and transport Relative humidity Vibration (during transport)
Seismic stress Shock loading EMV - requirements 6.8 Mechanical data 19' rack-mounting system acc. to DIN 41 494/ IEC 60 297 (1 pitch unit (PU) = 5.08 mm)
Plug-in modules Front-panel height Front-panel width Circuit-board dimensions Board connectors Front-panel color Racks Overall width Mounting width for modules Overall height Internal wiring Page 15 of 17 Doc. -No. 5-0106 D22E Edition 44/01.06.2010 Edition / 01.06.2010 Page 15 of 17 Doc.-No. 5-0106 D22E
Non-proprietary Version Technical Information, DWK 250 Digital Wide Range Channel Appendix A.1 DWK 260 schematic diagram
((
1]
Edition 4 / 01.06.2010 Page 16 of 17 Doc. -No. 5-0106 D22E
Non-proprietary Version Technical information, DWVK 250 Digital Wide Range Channel Appendix A.2 List of technical documentation System TK 250 general documentation General Protection and Safety instructions 5-0125 A01 (E)
Standard Data for Digital Measuring System TK 250 25 438 D09(E)
Electronic modules: Technical information Various items List of type-tested components 25438-Ql 0 DWK 250 Digital Wide Range Channel DWK 250 User Manual 5-0106 A70E DWK 250 Quick-Reference Guide 5-0106 A50E DWK 250 Parameter list (form) 5-0106 D21 E DWK 250 Computer Interface 5-0106 B93E Theoretical background Wide range neutron fluence rate meter - Mean square IEC 61501 voltage method Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Muenchen Fax: +49 (0)89 51513-169 Examin. of contents: sign. WIB Author: MGPI-E, Si Doc.-No. 5-0106 D22E Formal release: sign. CR Page 17 of 17 Edition 4/01.06.2010 Mitteilung 5-10119
Non-proprietary Version MGP,,1&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement - Munich, Germany I
information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( ))
This is a non-proprietary version from which the proprietary I Neutron-Flux Monitoring Channels TK 250 DWK 250 Digital Wide Range Channel User Manual Interfaces Features Operation Application Notes Edibon 1 / 07.06.2011 Page 1 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Prefatory note:
A brief description of the DWK 250's features, information on its design, and technical data will be found in the publication "DWK 250 Digital Wide Range Channel - Specification / Technical Information,"
Doc.-No. 5-0106 D22E and have not been repeated here.
Page 2 of 43 Doc.-No. 5-8630 A7OE Edition /07.06.2011 Edition 1I /07.06.2011 Page 2 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Table of contents
- 1. Digital wide range channel interfaces ............................................................................................ 4 1.1 Detector and preamplifier connection ...................................................................................... 4 1.2 Pulse input (( )) ............................................................................ . 4 1.3 (( 11............................................................................................................ 5 1.4 Analog inputs ................................................................................................................................ 5 1.5 Binary inputs ................................................................................................................................. 5 1.6 Analog outputs ............................................................................................................................. 6 1.7 Binary outputs .............................................................................................................................. 6 1.8 Control panel ................................................................................................................................ 7 1.9 Serial interface (optional) ...................................................................................................... 7
- 2. Functions of the digital wide range channel ................................................................................. 9 2.1 Processing of the detector signal ............................................................................................ 9 2.2 Signal processing handled by the NZ 21 1/0-processor ......................................................... 9 2.3 Signal processing by the NZ 12 central processor ................................................................ 12 2.4 Displaying and operator entries ............................................................................................. 16 2.5 Test procedures ......................................................................................................................... 16 2.6 Self-M onitoring ........................................................................................................................... 18
- 3. Operating the signal channel ........................................................................................................... 20 3.1 Display of measured values and messages ........................................................................... 20 3.2 Key assignments ........................................................................................................................ 21 3.3 Operating and accessing table .............................................................................................. 21 3.4 Dialog procedures ...................................................................................................................... 22 3.5 Status procedures ...................................................................................................................... 24 3.6 Parameter procedures ................................................................................................................ 25 3.7 Test procedures ......................................................................................................................... 28
- 4. Application notes .............................................................................................................................. 31 4.1 Range of applications ................................................................................................................. 31 4.2 System integration ...................................................................................................................... 31 4.3 Com missioning .......................................................................................................................... 31 4.4 Periodical testing ........................................................................................................................ 32 Appendix A.1 DW K 250 schem atic diagram ............................................................................... 33 Appendix A.2 DVVK 250 signal circuit .......................................................................................... 34 Appendix A.3 Operating and accessing table, parameter table .................................................. 35 Appendix A.4 List of inputs and outputs ........................................................................................ 36 Appendix A.5 List of message texts ............................................................................................ 37 Appendix A.6 Texts and dimensions of measured- and diagnostic values ................................... 37 Appendix A.7 Default parameters of the central processor ........................................................ 38 Appendix A.8 DWIK250 1/0-processor EPRO M-parameters ....................................................... 40 Appendix A.9 Periodical testing procedures ................................................................................. 41 Appendix A.10 Term inology and abbreviations em ployed ............................................................. 43 Edition 1 /07.06.2011 Page 3 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel
- 1. Digital wide range channel interfaces For schematic diagram, refer to Appendix A. 1 For a list of inputs and outputs, refer to Appendix A.4 1.1 Detector and preamplifier connection The operating voltage (approx. 100 ... 800 V) for the detector is supplied by an adjustable high-voltage power supply (e.g., an NH 36, unit) installed in the central electronics unit. The detector input is supplied by the following combination of TKV 23 preamplifier, filter and resistant. An integrated voltage divider allows voltage monitoring of the detector. The central electronic also supplies the operating voltage (+/- 15 V) for the preamplifier and delivers the control signals for the change-over of the amplifier and test generators. The transmission of the operating voltage, the pulse signal and the AC- signal is performed via three coaxial cables.
detector preamplifier main electronic rack I
L ..
I analog signal processing >I digital signal processing I,
1.2 Pulse input (( 11 The central electronics of the wide range channel provides one counter input with a pulse discriminator for the pulse path. In the signal channel, those pulses that exceed a preset threshold of the NI 21 pulse discriminator will be counted. ((
I]
Edition 1 / 07.06.2011 Page 4 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 1.3 (( 1] input module The preamplifier provides an AC-signal ((
1]
1.4 Analog inputs One of the NZ 21 I/O-processor's analog input is used for acquisition of the correlator signal, the others are used for monitoring voltages:
1.5 Binary inputs On the digital wide range channel a pair of binary inputs on the NZ 21 I/O-processor handles enabling autoranging upshifts/downshifts (change-over of the measuring range). A further pair of binary inputs on the NZ 12 central processor may be used to enable testing procedures and parameter set-up.
Locking and enabling of these functions is normally handled by the NS 01.12 key-switch module.
[C 11 Edition 1 / 07.06.2011 Page 5 of 43 Doc.-No. 5-8630 A70E
Non-proprietary VersiOn User manual, DWK 250 Digital Wide Range Channel 1.6 Analog outputs One of the four analog outputs on the NZ 21 I/O-processor is used internally for control of the discriminator threshold. The three available outputs are used for signal outputs. Two analog outputs are adjustable by parameters in terms of measured value and measuring range. An additional analog output is provided by the NA 33 AC-input module.
11 11 1.7 Binary outputs 1.7.1 Operational alarms and messages Isolated relay contacts for status messages of adjustable alarms may be controlled by eight binary outputs on the NZ 12 central processor via the relay drivers on the NB 21 or NB 28 modules. If necessary, the relay drivers may also be controlled by the NZ 21 I/O-processor, e.g.:
((
Page 6 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 6 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 1.7.2 Test procedures Five binary outputs on the NZ 12 central processor are used for activation of test generators in the TKV 23 preamplifier and input modules of the pulse and AC-path.
((
11 1.7.3 Control of measuring ranges 1]
1.7.4 Trip alarms for reactor-protection applications The NZ 21 I/O-processor is capable of generating three trip alarms whose settings are configured on a project-by-project basis and therefore cannot be later changed by operator access or due to "human errors".
((1 The binary signals are also available as potential-free relay contacts via the NB 21 or NB 28 module (principle of standby current).
1.8 Control panel The control panel on the NZ 12 central processor's front panel is the built-in user interface of the signal channel. The eight function keys on its front panel allow controlling its operation via user entries. The two-line alphanumeric liquid-crystal display with 16 characters per line is used for displaying measured values and text messages.
Cf. Section 3 for further information.
1.9 Serial interface (optional)
Edition 1 /07.06.2011 Page 7 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel An external computer may be used for reading all information (measured values, status messages and parameters) and operating all functions (e.g., parameter set-up and testing) of the signal-channel via the NK 21 serial interface.
The functions and op-codes of the data interface are described in the manual, "DWK 250 Computer Interface", doc.-no.5-0106 B93E.
Page 8 of 43 Doc. -No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 8 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, D.WK 250 Digital Wide Range Channel
- 2. Functions of the digital wide range channel For the DWK 250 signal circuit, refer to Appendix A.2 2.1 Processing of the detector signal Following to the common input stage of the (( )) preamplifier, the pulse and AC-signal are processed by separated amplifier stages which are optimized for the respective signal. Fast pulses with an amplitude of up to 2500 mV are available at the pulse output for transmission via long coaxial cables.
Incoming pulses preprocessed by the (( )) discriminator are transferred to the central electronics of the wide range channel. All pulses which exceed the adjustable discriminator threshold are provided as standard pulses for further processing by the pulse counter. ((
The AC-signal is provided via a buffer amplifier [
11 1[
))
2.2 Signal processing handled by the NZ 21 1/0-processor The I/O-processor is used for signal processing of the in- and outputs and for control of the hardware.
In addition it performs preprocessing of the signal and supplies directly signals (with a minimum of software) for the reactor protection system. The NZ 21 module is self-sufficient in its function.
Page 9 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 9 of 43 Doe.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 2.2.1 Pulse path
[I
))
2.2.2 AC- path
((
1]
Page 10 of 43 Doc. -No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 10 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 2.2.3 Analog inputs and outputs In addition to the analog input used by the correlator signal, there are three analog inputs used for voltage monitoring. These inputs and four analog outputs of the NZ 21 module are operated cyclically every 100 ms. (cf. also Section 1.4 and 1.6).
2.2.4 Alarm monitoring The two filtered measured values (count rate and AC-signal) can be monitored by up to eight alarms within the NZ 21 I/O-processor and a hysteresis may be defined for every alarm. Three binary outputs are available for indicating alarm messages. The alarm messages may be linked logically before.
For each alarm the following parameters are configured and stored in the EPROM:
- Mode of alarm (low alarm, high alarm, or no alarm specified)
- Alarm threshold, reset threshold
- Assignment to count rate or AC-signal
- Assignment and logical link to binary output Page 11 ot43 Doc-No. 5-8630 A7OE Edition 11107.06.2011 Edition / 07.06.2011 Page 11 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 2.2.5 Time response As well as the "linear count rate" signal, filtering and calculation of alarms of the AC-signal located on the NZ 21 module, the time behaviour of the signal processing is described in the following statements (worst case):
[I 1]
The time constants used for the low-pass filter, (( 11 on the NZ 21 module are stored in the EPROM (configured).
2.3 Signal processing by the NZ 12 central processor In the DWK 250 digital wide range channel, the signal paths with the most-stringent safety requirements are handled by the analog signal processing or the I/O-processor, rather than by the central processor. The central processor needs measured values supplied by the I/O-processor for the purpose of calculation further characteristic values for the start-up behaviour of a reactor, e.g.
wide range-signal and reactor period. The central processor uses this information for generating other adjustable alarms, displaying measured values on the display, and transmitting them to an external computer. In the opposite direction only parameters set by the user may be transferred to the I/O-processor via the central processor.
2.3.1 Pulse path
))
2.3.2 AC-path The AC signal supplied by the NZ 21 i/O-processor is (( 11 is acquired by the central processor resulting as "AC signal raw'. ((
1] Similar to the dead-time correction, a correction of the detector saturation can be performed for the AC signal.
Page 12 of 43 Doc.-No. 5-8630 A7OE Edition 11107.06.2011
/ 07.06.2011 Page 12 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 1[
11 11 2.3.3 Calculation of the wide range-signal 1]
2.3.4 Filtering and calibration of the neutron flux signal The wide range signal is multiplied by an adjustable calibration factor and then filtered ((
)) These calculation steps are used for determination of the 1] neutron flux signal (cf. also Section 2.3.6).
Page 13 of 43 Doc-No. 5-8630 A7OE Edition I1107.06.2011 Edition / 07-06.2011 Page 13 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 2.3.5 Calculation of the change rate The change rate (unit "e-2 1/s", linear scaling) is the reciprocal of the reactor-period (unit "s",
reciprocal scaling), and may be interpreted as "%Is" for small signal changes.
((
I1 The wide range signal is differentiated by forming the difference quotient ((
1]
((
11 Page 14 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011 Edition /07.06.2011 Page 14 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 2.3.6 Calculation of the filter time constant 11 2.3.7 Adjustable analog outputs Two analog outputs of the NZ 21 1I0-processor are scaled by the NZ 12 central processor considering the following adjustable parameter (see also section 3.6.5):
- Assignment to measured value
- Linear or logarithmic scaling
- Measuring range (start of range, end of range) 11 11 Please notice:
When setting parameter of logarithmic analog signals the values of measuring range (start of range, end of range) must be positive (> 0)!
Edition 1 / 07.06.2011 Page 15 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 2.3.8 Adjustable alarms As many as 16 alarms may be routed to eight binary outputs. For each alarm the following parameters may be adjusted (see also section 3.6.4):
Assignment to measured value Mode of alarm (Low alarm, high alarm)
Value of alarm threshold Percentage of the hysteresis (% of threshold)
Binary output for alarm messages The monitoring cycles are hierarchized:
((
If one or more alarms assigned to the indicated measured values have been violated, the letter "A" will be shown on the measured value display.
2.3.9 Parameter memory The central processor stores values of its parameters, along with a checksum, in a battery-buffered CMOS-RAM. Stored parameter settings will be retained in its memory, even if a power outage occurs or the module is placed in storage.
Stored parameter settings may be manually changed via the front panel only, if the "enable parameter' binary input signal is active. The number of parameter setting procedures is not limited.
2.4 Displaying and operator entries All values of measured values and parameters, as well as status information, may be readout on the two-line display using the function keys. The continuous signal processing will be unaffected by the choice of items called for display. Signal processing and operational procedures proceed in parallel and are mutually independently.
Whenever parameter settings are changed by the user, the changes will not become effective until the "store"-key has been pressed and parameter key-switch has been enabled. After this procedure continuous signal processing will use the new parameters.
2.5 Test procedures Various built-in test and simulation procedures may be activated by using the front-panel function keys or via serial interface with a connected external computer. Launching test routines using the function keys requires that the test-enabling signal is set, e.g., by the key switch on the NS 01-module.
Page 16 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 16 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Canceling the setting of the test-enabling signal will automatically disable test procedures on the reactor-protective path. However, test status will have to be disabled using the associated test procedure, since otherwise the "test disabled" error message will remain active.
The test mode of the wide-range channel will be reported:
((
For more information on the necessary procedures, refer to Section 3.7.
2.5.1 Testing binary outputs The eight binary outputs, BO 1.1 ... BO 1.8, and I/O-processor binary outputs may be set or reset.
After completion of testing the switching states based on the signals will become effective again 2.5.2 Test generators The test-signal generators on the input modules may be remotely activated.
((
The set points of the test signals are described in the respective technical information of the modules.
It hast to be noticed that the double count rate may be displayed when checking the pulses of the preamplifier's test generators with long attached detector cables. Test pulses may be reflected at the detector and could be counted twice.
2.5.3 Simulation The measured signals, e.g., pulse count and AC-signal may be overwritten with simulated values, i.e.,
manually entered numerical values.
Simulated values may be also used for the two adjustable analog outputs (cf. also Section 2.3.7).
2.5.4 Testing with external equipment As in the case of analog signal processing, signals from external test equipment may be transmitted to their respective inputs of the digital wide range channel. In this case, the test status may be generated by enabling testing while retaining internal signal paths.
Edition 1/ 07.06.2011 Page 17 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 2.5.5 Testing the display This test procedure activates all pixels on the display and can only be initiated from the front panel, requires no enabling, and generates no test status.
2.5.6 The "Watchdog" test This test artificially interrupts execution of the program running in order to intentionally trigger activation of "Watchdog" monitoring of the central processor. Once that has been triggered, the signal channel will be restarted. Any test procedures that may have been activated will be reset. Stored parameter settings will be retained (cf. also Section 3.7.6).
2.6 Self-Monitoring If either the I/O-processor or central processor detects a malfunction, the signal channel will remain in operation as far as possible and a fault message will be generated:
The causes of malfunctions may be displayed either from the front panel, via the "Status / Faults" dialog procedure, or via the computer interface. The fault messages that will be generated and their possible causes and remedies are as follows:
((:
11 Detected faults are indicated even the cause of the malfunction (e.g. transient voltage deviation) has been eliminated. The fault messages will remain stored in memory until the system is restarted (e.g."*Vatchdog"). Fault messages concerning voltage monitoring or PAR-RAM check are deleted with the "store" key by using the parameter dialog provided the enable signal has been set.
Fault messages marked with characters "F" or "P" which are listed in the "Remedy" column may be cancelled by the user or new parameter settings.
Edition 1 / 07.06.2011 Page 18 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel All other fault messages will remain stored in memory until the system is restarted by the "Watchdog" test, W, or until the electrical supply line is interrupted, S, even if the malfunction involved occurred only for a short time.
2.6.1 Monitoring the NZ 21 1/0-processor 2.6.2 Monitoring the NZ 12 central processor
((
11 2.6.3 Monitoring voltages Measured values of "voltages" (cf. Section 1.4), i.e., of a "high voltage monitoring signal" which is proportional to the detector voltage, "operating voltage" and the "discriminator voltage" will be acquired and cyclically monitored by the central processor in order to determine whether they are within preset limits. The end of range for each voltage, along with the lower and upper thresholds of the monitoring windows, may be set by parameters.
2.6.4 Monitoring the (( )) filter 1]
Page 19 of 43 Doc. -No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 19 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel
- 3. Operating the signal channel The signal channel may be operated from the front control panel, i.e., the keyboard and the display, and via the NK 21 serial computer interface. The two options are equivalent, cover all functions, and may be used in parallel.
The following description apply to "operation from the front control panel" only, i.e., operation using those operating controls provided by the channel itself. T U; The operation via an external computer is described in a 3.456e+1,2 Neutr. flux nv, TAF separate manual.
The front control panel provides the following functions:
" Display of measured values
" Display of status information
- Display and setting of parameters
- Activation of testing procedures User entries for the signal channel are performed using the eight function keys situated on the NZ 12 central processor's front panel. Measured values, parameter settings, status information, etc., will be displayed on a two-line, liquid-crystal display.
3.1 Display of measured values and messages Intermediate results and final results of the signal processing may be displayed as either "measured values" or "diagnostic values" on the display. The separation between "measured values" and "diagnostic values" is made in order to allow a clearly organized display of the most important results in the leftmost column of the menu table. Alarms may be assigned to measured values and diagnostic values.
Measured value Information on the status of measured (inexponent format or fixed format) values (status messages) will also be displayed. 1 *Physical units (of the measured value)
"T," "A," or "F" status messages will be .123u+02 cps indicated by appearance of the Pulse count T' Status messages associated character on the display. T: Testing mode Status messages will appear thereon A: Alarm value exceeded only while cyclic display of measured F: Malfunction detected values is active.
- Name of measured value Fig.: Layout of the display for measured values Edition 1 / 07.06-2011 Page 20 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.2 Key assignments The assignments of functions to the keys is the same as for all other monitoring channels of the TK 250 system.
Display-panel illumination may be switched on with the ((
"light" key and will automatically switch off if no key is pressed before a certain time period has elapsed.
))
3.3 Operating and accessing table The display for measured values and dialog procedures are summarized in the columns of an operating and accessing table. The display may be moved like a window over this table using the four cursor-control keys.
Rough positioning is effected column-by-column using the "right"r'left" cursor-control keys, which will cause the column headings to appear on the display. Fine positioning within a column is effected by using the "up"/"down" cursor-control keys. The vertical-positioning operation has no lower and upper limit, i.e., after the lowermost item of a column is reached it follows the topmost item, i.e., the column heading, and vice versa. The cursor will skip to the next / preceding item within the column when the lower / upper end of a column is reached (Wrap-around function).
For easier identification, column headings are underlined and the designations of dialogs are followed by a colon. A dialogue procedure that has been highlighted may be entered by pressing the "enter/next" key.
When the digital wide range channel is switched on, the first measured value at the "default position",
e.g., "Neutron flux", will be automatically displayed. Confirmation by pressing the "exit" key (the "cursor home" key) while in the accessing table will also display the first measured value.
Dialog procedures split longer operation procedures into a series of steps and guide users through dialogs. Within a dialog procedure, user input and text output will alternate on the display. Parameter settings may be changed only within the dialog procedure.
The ability to configure the digital wide range channel on a project-by-project basis includes that the number of entries and their descriptions appearing on the operating and accessing table are configurable and thus adaptable to particular projects.
The menu tables for a typical configuration of the DWK 250 is shown in.Appendix A.3.
Edition 1 / 07.06.2011 Page 21 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.4 Dialog procedures Within the columns "Status", "Parameters" and "Testing", the dialog procedure needed is selected by using the "up"/"down" cursor-control keys. The dialog is entered and stepped through by pressing the "enter/next" key. Dialog procedures may be exited at any time by pressing the "exit' key.
VWithin a dialog step the "up/down/left/right" keys are used to change (edit) parameter settings. WMthin the parameter procedures, changed parameters are stored by pressing the "store" key and at the same time the dialog is exited. Exiting a dialog procedure leads the user back to the access table: The name of the dialog procedure is displayed.
Please note:
When entering parameters, only some of the values entered will be checked for plausibility.
))
3.4.1 Editing numerical entries The display of a floating-point number to be edited is 2.054e+02, signifying 2.054 times 10 to the power of two, or 205.4.
Numbers are edited character by character, where the character that may be edited is marked (underlined) by the cursor. Use the "right"/"left" cursor-control keys to position the cursor, where the decimal point and the "e" will be skipped. Entering negative numbers will be locked in some cases (an existing negative algebraic sign may be deleted, but cannot be restored).
Pressing the "up"f'down" cursor-control keys will increment/decrement the value of the marked position by the cursor (principle as a thumbwheel switch). Leading zeros will be suppressed in the case of numbers displayed in fixed-point format.
Page 22 of 43 Doc-No. 5-8630 A7OE Edition 1/07.06.2011 Edition 1 /07.06.2011 Page 22 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.4.2 Editing texts (plant code)
Texts are edited character by character, where the "left"/"right" cursor-control keys are used to position the cursor and the "up"'"down" cursor-control keys will cycle the character being edited through the following sequence:
The numerals "0" through "9," the letters "A" through "Z," ,,-," a decimal point, a slash, a colon, and a blank.
3.4.3 Selecting item numbers Similar items, e.g., the 20 entries in the table of alarms or the eight binary outputs for reporting them, are arranged by item numbers. A displayed item number may be cycled through its available range by using the "up"f"down" cursor-control keys.
Pressing the "down" cursor-control key will shift the cursor one item down in the table, i.e., shift it to the next higher item number.
3.4.4 Specifying assignments Texts, and their associated assignments, may be selected from a list of predefined texts. For example, existing measured values may be routed to any of the alarms to be adjusted. The "up"/'down" cursor-control keys may be used to select the desired measured value from the list of predefined texts. The text selected will be shown on the display.
3.4.5 Locking user access Changing parameter settings and activating of test generators or numerical simulation cause an access in signal processing and may be locked. Locking user access is possible by using the two key switches on the NS 01-module and the pair of binary inputs on NB 21:
Unlocking by using the LED-display Function key switch on NS 01 on NB 21 enabled Upper (black) key switch set to "I"(ON) E 3 lights up Testing Lower (red) key switch set to "I" (ON) E 4 lights up Parameter setting Page 23 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011
/ 07.06.2011 Page 23 of 43 Doe.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.6 Status procedures 3.5.1 alarms If no alarm is exceeded, the message "No threshold violated" will be indicated, otherwise the following information for every alarm will be displayed:
-* number of the alarm
. alarm mode (high - low) 1a000er09 nV I
- alarm threshold J
a0 and: 1 name of the variable
- neutr.flux 1.1..880+09 nV 0 phys. units of the value 0 value 3.5.2 Fault messages of the internal self-monitoring The malfunctions which are detected by the internal self-monitoring (cf. Section 2.6) will be displayed (listed) by this dialog procedure. The list of error messages may be accessed and navigated through it by using the "enter/next" key and exited by pressing the "exit" key 3.5.3 Software identification The designation of the DWK 250 digital wide range channel and the identification number of the central processors software will be displayed by this dialog procedure Page 24 of 43 Doc-No. 5-8630 A7OE Edition 1/07062011 Edition 1/ 07,06.2011 Page 24 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.6 Parameter procedures This group of dialog procedures allows reading and editing the parameter settings of the NZ 12 central processor, and, as far as accessible, also the parameter settings of the NZ 21 1/0-processor.
The monitoring channel will continue its operation by using the actual parameter set, even while a parameter dialog is in progress. Changes of parameter settings will not apply until the "store" key is pressed, provided that the related enabling signal is present (cf. Section 2.5). If no enabling signal is present, the following message "parameters are locked" will be displayed on the measured display.
No enabling signal is required to change the parameter via serial interface.
Setting new parameter or changing parameter has to be performed carefully, because the function of the complete channel is influenced by parameter setting (a prepared parameter list should be used).
3.6.1 General settings Within the dialog procedure "General settings" the following parameters can be selected for by repeatedly pressing the "enter/next" key on the front panel of the DWK 250:
((1 3.6.2 Time constants This section summarizes parameters used by the control of the time constant for filtering of the neutron flux and change rate:
11 1]
Page 25 of 43 Doc. -No. 5-8630 A7OE Edition /07.06.2011 Edition 1I /07.06.2011 Page 25 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.6.3 Voltage monitoring This section summarizes the ranges (end of range) and tolerances (lower/upper threshold) to be applied in. monitoring internal voltages (cf. also Sections 1.1 and 2.6.3).
((1 3.6.4 Alarms The dialog for setting alarms pass through to each of the 16 adjustable alarms (cf. also Section 2.2.4).
((]
Edition 1 /07.06.2011 Page 26 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.6.5 Analog outputs This dialog is used for adjusting analog outputs:
Caution:
When using logarithmic scaling the values of measuring range (start of range, end of range) must be positive (> 0)!
3.6.6 Select dimensions The following texts and physical dimensions can be assigned to all measured values and diagnostic values which do not have already a fixed dimension.
((
3.6.7 Plant code This dialog is used to enter a 16-character alphanumeric plant code (cf. also Section 3.4.2).
Edition 1 / 07.06.2011 Page 27 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wde Range Channel 3.6.8 Default parameters Caution!
The following procedure should be performed in special cases only. Loading default parameters will delete existing parameters. Default parameters may be not adapted to the individual measurement tasks.
This dialog procedure allows loading the predefined default parameter settings into the memory of the wide range channel (cf. Appendix A.7). Since, in most cases, these default parameters will not comply with the desired settings, the settings needed for a specific task will have to be subsequently reentered. The following dialog has to be confirmed by using the "store" key Load default parameters ?
If the "enabling parameter set-up" signal B14 is not available, the message "Access denied?" is displayed, i.e. the default parameters are not stored in memory and the previous values will remain unchanged.
3.7 Test procedures Activation of test procedures will be enabled only while the "enable testing" signal, e.g. key switch, (see section 3.4.5) is present. Otherwise, their activation will be disabled and the message "Test functions are locked!" will appear on the display.
Test procedures will become effective immediately upon setting, and, except for the binary-output test, will be stored after the dialog procedure is exited by pressing the "exit' key, but will not be stored following a power failure or a 'Watchdog" test.
There is no enabling signal required for checking the wide range channel via the serial interface (e.g.
with a portable PC) with the exception of activation of test generators (3.7.2). It is not possible to activate the test procedures "Display" and 'Watchdog" (3.7.5. and 3.7.6) via the serial interface.
Page 28 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011
/07.06.2011 Page 28 of 43 Doe.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.7.1 Testing binary outputs This dialog allows overwriting binary outputs BO 01... BO 06 and BO 08 controlled by the central processor:
select number of the binary output (1 to 8) with key "enter I next' Binary output 1 select test signal for the binary output (X/0II) with keys "up" and "down" (X= original status)
The binary outputs can be overwritten with test signals "0" or "I". "X" is used for the original status.
The test status message BO 07 itself is not checkable in the same way, it is already set when entering the dialog and will be reset after leaving all testing procedures.
Upon exiting dialog mode by pressing the "exit" key, all test signals will be automatically terminated and the original signals will be active (cf. Section 2.5.1).
3.7.2 Test generators for input modules This dialog procedure allows activation of test generators in the preamplifier and in the NI 21 and NA 33 input modules (cf. also Section 2.5.2).
[f The activation of this test generators is used for checking the reactor-protection signal paths. This dialog procedures requires the "Enabling testing" signal BI 3 when entering the dialog via the serial interface If the enabling of testing is retracted during a test procedure, test procedures will be interrupted and the fault message "Testing locked" will be generated in the "Status / Faults" dialog procedure. The
'test status message" (BO 07) will remain active.
Page 29 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 29 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 3.7.3 Simulating measured values This dialog procedure allows presetting the numerical values of "pulse count" and "AC signal normalized" as well as for analog outputs 1 and 2 as substitutes for signals received from the process.
It is used for testing the signal processing of the channel and attached peripheral device (cf. also Section 2.5.3.)
((
1]
3.7.4 Global test status This dialog supports checking of the wide range channel by using external testing equipment. The functions of the channel remain in normal operating status and the "test status message" (BO 07) is set and will continue during the following test procedure.
[1 1]
3.7.5 Testing the display All pixels will be activated on the display in order to test the display panel (cf. also Section 2.5.5).
3.7.6 Test of the program sequence monitoring ('Watchdog")
This routine allows testing the operation of the "Watchdog", the program sequence monitoring. If the reply to the prompt "Test watchdog circuit?" is pressing the "enter/next" key, the message "Re-start in 10 seconds!" will be displayed. Access by the user and thus aborting the procedure will be disabled.
Signal processing by the central processor will be halted in order that the signal for the 'Watchdog's" timer will be interrupted. The I/O-processor will continue its operation, but will generate an error message, since its link to the central processor is interrupted, too. As soon as the response time of around ten seconds has elapsed, the NZ 12 central processor will be reset and restarted (cf. also Section 2.5.6). The existing (in steady state) measured values will not be stored in memory.
Edition 1107.06.2011 Page 30 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel
- 4. Application notes 4.1 Range of applications The DWK 250 digital wide range channel has been designed for centralized neutron-flux instrumentation used in the control rooms of nuclear power plants and on research reactors.
4.2 System integration The entire system consisting of detector, preamplifier, and monitoring channel, which can take up a considerable amount of distance, is DC-coupled and must be grounded at a single point only. In particular, the grounding point should be optimized for high interference suppression.
Connections to the analog and binary signal outputs, as well as the power supply, are isolated via the NT 31/61, NR 31, NB 21/28 and NN 43/53 modules. Precautions should also be taken against undesired ground potentials and signal feedback in the case of other signal inputs and outputs (e.g.,
those for interlocks or measurement-range displays). Connections to the detector must employ suitable coaxial cables, and, if necessary, should have an additional guard-shield connected to power-station ground.
4.3 Commissioning The detector voltage should be adjusted to a lower voltage level before commissioning. The exact value of the voltage can be adjusted after parameter setting of voltage monitoring and by help of the integrated voltmeter.
If the digital wide range channel has a valid parameter set in its nonvolatile parameter memory on startup, it will use this stored parameter set and show the first measured value at the default position of the display. A valid measurement result will then appear thereon within a few seconds.
If no valid parameter set is available on startup because a new memory chip Paaete 1 has been installed or data has been lost, the channel will load the default set default values of parameters and show this text on the display:
As soon as receipt of that message has been acknowledged by pressing any key, the normal measured value display will appear on the display. The channel will also generate the error message "PAR-RAM fault," which will remain displayed until an alternative setting of at least one parameter has been transferred to its parameter memory using the "store" key.
Since the default parameters will normally not comply with the desired set of parameters, a complete parameter set-up is recommended if the above message appears when the channel is started up.
A list of default parameter settings appears in Appendix A. 7.
When the digital wide range channel is switched on, all test procedures will be reset, i.e., the channel performs its normal measuring function according to the actual stored parameter.
Page 31 of 43 Doc-No. 5-8630 A7OE Edition 1I //07.062011 07.06-2011 Page 31 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel 4.4 Periodical testing The testing and simulation routines incorporated into the digital wide range channel and supported by operator dialogs allow performing periodical testing without using external test generators and, more importantly, without interference in the wiring.
The periodical testing can be automated via the NK 21 serial interface with connected computer.
When testing a digital channel, it should be kept in mind that accurate control of the precision of the functions involved, e.g., the precision of calibration and the precision of alarm thresholds, that have been set up in the program, i.e., in its EPROM, makes little sense. Those testing procedures were included in type testing, and need not be periodically repeated, since they are stored in its EPROM, whose content is continuously monitored.
The test status message is set at the beginning of test procedure by enabling the test locking device, i.e. NS 01 key switch, and will continue during the following test procedures. The internal test settings will be automatically reset whenever the channel is restarted as a result of the 'Watchdog" test. Test of the signal channel should be completed with a check of all parameter settings.
Periodical testing procedures are described in Appendix A.9.
Note:
During power operation of a BWR wide range detectors normally are withdrawn from the reactor core.
Even in this situation a wide-range fission chamber generates both pulses and AC-signal which allow the functional monitoring of the complete measurement setup.
Page 32 of 43 Doc. -No. 5-8630 A7OE Edition 11/07.06.2011
/ 07-06.2011 Page 32 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.1 DWK 260 schematic diagram
[I
))
Page 33 of 43 1 /07.06.2011 Edition 1/ 07.06.2011 Page 33 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.2 DWK 250 signal circuit
((
Edition 1 /07.06.2011 Page 34 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.3 Operating and accessing table, parameter table
((]
Page 35 of 43 Doc.-No. 5-8630 A7OE 1/07.06.2011 Edition 1/ 07.06.2011 Page 35 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.4 List of inputs and outputs NZ 21 1/0-orocessor Assignments of signals to component connectors are configurable. The following list is therefore a sample of a connector-pin assignment.
((
1]
NB 21 binary inputs/outputs
((
11 Edition 1 / 07.06.2011 Page 36 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.5 List of message texts 1]
Appendix AX Texts and dimensions of measured- and diagnostic values Neutron flux nv, P/Pn, Pn Change rate 1Is Pulse count I/s, cps AC-Signal norm. l/s, cps Wide range signal l/s, cps N. flux dbl. filtered nv, P/Pn, Pn Raw pulses I/s, cps Ratio Ni/Np Time constant s, sec Internal voltage Volt Detector voltage Volt Discr. voltage Volt Page 37 of 43 Doc.-No. 5-8630 A7OE Edition 1I //0706.2011 Edition 07.06.2011 Page 37 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.7 Default parameters of the central processor Default values of the parameters are stored in the EPROM and will be used automatically in case of parameter loss; These values may be overwritten by the user.
- 1. General settings:
Discrim. threshold Dead time Saturation correction AC normalizer Neutr. flux calibr. factor Overlap start Overlap end
- 2. Time constants:
CR_lo TAU (CR-lo)
CR_hi TAU (CR_hi)
TAU deviation
- 3. Voltage monitoring:
Det. voltage end of range Det. voltage lower threshold Det. voltage upper threshold Internal voltg. Lower threshold Internal voltg. Upper threshold Discr. voltage lower threshold Discr. voltage upper threshold Page 38 of 43 Doc-No. 5-8630 A7OE Edition /07.06.2011 I 107.06.2011 Edition 1/ Page 38 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Continuation of Appendix A.7
- 4. Alarms:
Nr. Meas.val./thresh. Mode/Hysteresis Bin.Outp. Meaning Alarm 1 ((
Alarm 2 Alarm 3 Alarm 4 Alarm 5 Alarm 6+7 Alarm 8 Alarm 9...16 ))
- 5. Analog outputs:
Analog output I ((
Analog output 2
- 6. Dimension:
Pulse count ....
Wide range signal Neutron flux Time constant
- 7. Plant code: 1]
Plant code =
Page 39 of 43 Doc-No. 5-8630 A70E Edition 1/07.06.2011 Edition 1/ 07.06.2011 Page 39 of 43 Doe.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.8 DWK 260 I/O-processor EPROM-parameters These parameter must be defined on a project-by-project basis, an additional change of it requires the exchange of the EPROMs, therefore the following values are examples only.
- 1. Pulse path:
Time constant Discr. threshold (start)
Analog output (start of range)
Analog output (end of range)
- 2. AC path:
Time constant Locked upper meas. range Locked lower meas. range Measuring range up time-lock Measuring range down time-lock Upper threshold autoranging Lower threshold autoranging
- 3. Alarms:
Alarm 0: Mode Measured value On threshold Off threshold Binary output Alarm 1: Mode Measured value On threshold Off threshold Binary output Alarm 2: Mode Measured value On threshold Off threshold Binary output This alarm is not effective in the 12h measuring range!
Page 40 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011
/07.06.2011 Page 40 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.9 Periodical testing procedures
- 1. Inspection of the equipment status 1.1 Monitoring system status and eliminate any fault messages 1.2 Check of the operating voltage ("Diagnostic values')
1.3 Check of the high voltage 1.4 Check of the discriminator voltage
- 2. Analoa inputs
((
1]
- 3. Analoq outputs
((
11
- 4. Binary inputs Check the testing and parameter lockouts, together with enabling of the NZ 21 release, in both logical statuses.
- 5. Binary outputs
((
1]
Page 41 of 43 Doc-No. 5-8630 A7OE Edition 11/07.06.2011 Edition / 07.06.2011 Page 41 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel
- 6. Pulse path 11 11
- 7. AC-path
((
- 8. Measuring ranqe chanae-over
[I 11
- 9. System operation 9.1 Initiate a 'Watchdog" test:
The processor will be restarted and all test procedures and error messages will be reset.
9.2 Perform a display test 9.3 Parameter check:
Check all parameters that may be read out, particularly the calibration factor, together with the EPROM's checksums and the software version number.
Periodical testing procedures should be terminated with testing procedure 9.3, i.e., a parameter check. The order in which the other testing procedures are performed may be chosen based on practical considerations.
Page 42 of 43 Doc-No. 5-8630 A70E Edition 11/07.06.2011
/07.06.2011 Page 42 of 43 Doc.-No. 5-8630 A70E
Non-proprietary Version User manual, DWK 250 Digital Wide Range Channel Appendix A.1O Terminology and abbreviations employed Term SymboVUnits Definition Parameter Any variable whose value may be set by the user.
Configuration A combination of hardware, software, and selected functions and factory software settings Neutron flux (density) 1lnv = 1cm 2 s7' The number of neutrons crossing unit area per unit time Relative reactor power P/Pnominal Relative reactor output power, as determined from neutron-flux measurements Reactor period T (s) Time during which neutron flux increases by a factor of e = 2.72 Change rate 1/T (%/s) Relative neutron-flux change rate Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Muenchen Fax: +49 (0)89 51513-169 Examin. of contents: sign. EL Author: MGPI-E, BH Doc.-No. 5-8630 A70E Formal release: sign. CR Page 43 of 43 Edition 1/07.06.2011
/4i 117-oq Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 File: <hub6.dwk250>pf12.txd, Translatedfrom German to English on 2013-02-14 ersion from which the proprietary Tinformation has been rem(
his is a non-proprietary vcoved according to 10 CFR 2.390.
In this document the re moved sections of proprietary information are indicated by two opening and two closing brackets as shown here: 1((
=]
FUNCTIONAL SPECIFICATION for the WIDE RANGE CHANNEL DWK 250 Forwarding and reproduction of this documentation, utilisation and notification of its content is not permitted, unless consent is explicitly granted. Violations will lead to claims for compensation. All rights are reserved where a patent is granted or an invention registered.
Author: Muiller/EKS-M No.: 5-0106 D10E Edition: 2 of 29.01.88 Page: lof 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 Table of contents
- 1. Objective
- 2. Grouping of hardware and software
- 3. Signal conditioning on the (( 11 3.1 Impulse channel 3.2 Alternating current channel 3.3 Analogue outputs 3.4 Limit value monitoring 3.5 Time response 3.6 [1 11signal flow
- 4. Signal conditioning on the (( )) mai n processor 4.1 Signal flow 4.2 Conditioning of the pulse rat e 4.3 Conditioning of the correlatc3r signal 4.4 Formation of the (( 1]signal 4.5 Calculation of the measuremrent value and its relative change rate 4.6 Chronological behaviour of 11 )) algorithm 4.7 Determination of the filter ti me constant 4.8 Output of analogue values o n recorder 4.9 Monitoring of limit values 4.10 Parameter memory
- 5. Control 5.1 Control via the front panel 5.2 Control via the computer int erface Author: Muller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 2of18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250
- 6. Test functions, simulation
- 7. Monitoring 7.1 Monitoring of (( ] I/O processor 7.2 Monitoring of the [( 1] processor 7.3 Monitoring of high voltage and operating voltage 7.4 Monitoring of the recursive filter Author: MiuIler/EKS-M No.: 5-0106 D1OE Edition: 2 of 29.01.88 Page: 3of18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250
- 1. Objective The channels which were previously executed separately Impulse channel for the start-up range and Alternating current channel for the intermediate range are condensed into a single measuring channel with regard to signal conditioning.
Signal conditioning comprises the following key functions:
- Acquisition of the detector pulse counting sequence
- Acquisition of the alternating current correlator signal with automatic selection of the measurement range
- Combining the impulse path and alternating current path to form a common signal
- Filtering and calibration of the neutron flux signal
- Determination of the relative signal change rate (reactor period)
- Analogue signal output (e.g. for recorder)
- Monitoring of limit values Furthermore, the TK250 standard data (no. 25 438 D9) are valid for the wide-range channel.
- 2. Grouping of hardware and software The computer unit for the DWK 250 wide-range channel consists of 3 processor modules which are connected to one another loosely via a serial bus.
1))
Author: Mfiller/EKS-M No.: 5-0106 D1OE Edition: 2 of 29.01.88 Page: 4 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 1]
Software areas relating to reactor protection are only localised on [] Furthermore, processing on (( )) cannot be disrupted externally due to the (( )) separation of the processor boards. It is sufficient to apply a verification intensity of the software test, which corresponds to reactor protection requirements, only to the (( ]
As the software 1] is now considerably simpler to construct and is less extensive than the software on the main processor, this considerably reduces the testing expenditure for the proof of a certain software quality:
((
11 Author: MCIlIer/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 5of18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250
- 3. Signal conditioning on the [1 ))
Hardware and software (( )) module are only loosely coupled to the (( )) via the (( 1]
bus, and the [ ] also remains functional when the (( Fails.
f]
Transmissions via the (( )) whereby the data exchange between the
((
)) A start value is also stored in the EPROM for the discriminator threshold, but which can then be overwritten by the S bus.
3.1 Impulse channel All impulses which exceed a configurable discriminator threshold are counted [
))
The count rate is in the range of ((
The pulse rates totalled in the [ 1))are filtered with a [ and output as a linear count rate via an analogue output. The filtered count rate is monitored against a limit value.
3.2 Alternating current channel One (( )) input of the (( 11 acquires the output signal of the (( )) module.
The (( ] module filters the signal with a time constant (( ]
[F 1]
The [1 1] signal is filtered internally (( 1] and is then monitored against limit values.
11 1]
Author: Mller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 6of18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 3.3 Analogue outputs 11
(( 11 11 Author: MUIller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 7of18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 3.4 Limit value monitoring The filtered signals (( )) are internally monitored by
(( 11 limit values. A hysteresis can be defined for the limit values. (( 11 outputs are available to indicate the limit value status, whereby the binary outputs of the limit values can be logically combined.
For limit values monitoring the following parameters are configured in the program per limit value:
- Type of limit value (upper / lower limit value)
- Switch-on point, switch-off point
- Allocation to the monitored signal
- Logical combination
- Binary output 3.5 Time response
((
1]
Author: MOller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 8 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 3.6 [ )) signal flow
[I Author: MUller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 9of18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250
- 4. Signal conditioning on the (( 1] processor 4.1 Signal flow
[F 1]
4.2 Conditioning of the pulse rate The pulse counts occurring in F[
FE 4.3 Conditioning of the correlator signal
((
11 4.4 Formation of the (( 1] signal
((
1]
Author: M(ller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 10 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250
[1 11 4.5 Calculation of the measurement value and its relative change rate 1]
Author: Muller/EKS-M No.: 5-0106 DiOE Edition: 2 of 29.01.88 Page: 11 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250
[I
))
4.6 Chronological behaviour of (( 1] algorithm 1]
Author: MuIler/EKS-M No.: 5-0106 DI1E Edition: 2 of 29.01.88 Page: 12 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 In addition, the idle times stated in chapter 4.8 and 4.9 must be added for analogue value output or limit value monitoring.
4.7 Determination of the fifter time constant The fundamental course of the time constant TAU (( )) is as follows:
((1 The count rate and time constant are specified (( )) by parameterisation.
11 Author: Muiller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 13 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 4.8 Output of analogue values on recorder
[1 11 These analogue outputs shall use the following modifiable parameters:
Assignment to a selected measurement variable scaling of the analogue output (lin/log) measurement range 4.9 Monitoring of limit values Up to 16 adjustable limit values (( )) shall be provided by the wide range channel. The parameters of the limit values are:
Assignment to a selected measurement variable
- Type of limit value (ob/unt)
- Value of limit value
- Hysteresis of the limit value
- Binary output for limit value notification but graded monitoring cycles shall be applied for the limit values:
1]
4.10 Parameter memory The parameters of the wide-range channel and the corresponding checksum are stored in a battery-buffered CMOS-RAM. It is then only possible to change the saved parameters via the control panel if the binary input 'parameterising approval' is active.
Author: Miller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 14 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 S. Control It is possible to control the measuring channel both via the front panel (keyboard and display) and also via the NK 21 serial computer interface. Both control options are equivalent, span the entire scope of functions and can be used in parallel to one another.
Control includes the following functions:
-display / read of measurement values
- display / read of and input / recording of parameters
-display / read of status information
-triggering of test functions As the control concept is already accomplished in the (( )) and is transferred from there (uniform control concept in the TK250 system) it is only explained briefly hereinafter. Please refer to the following documents for a more comprehensive description:
((
1]
5.1 Control via the front panel Control entries for the measuring channel are inputted via 8 keys which can be found on the channels front panel. Control outputs are made via a 2 x 16 character LCD display.
Four positioning keys enable navigation in a matrix-shaped selection diagram which contains displays of measurement values and names of dialogue procedures.
The desired dialogue procedure is selected in a first control step. The dialogue is then entered with the aid of a 'GO' button and gradually advanced. Within the dialogue, the purpose of the 4 positioning keys is to edit values. Amended values are transferred to the parameter memory with the aid of the 'ENTER' button. A dialogue procedure is quit with the aid of the 'EXIT' button which takes the operator back to the selection diagram.
Author: Muiller/EKS-M No.: 5-0106 D1OE Edition: 2 of 29.01.88 Page: 15 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 5.2 Control via the computer interface The measurement channel can be controlled in its entirety via the NK 21 serial interface.
All functions which can be controlled via the front panel can also be controlled via the serial interface. As long as the executing functions do not contradict one another, parallel control via the front panel and computer interface is possible.
1[
1]
- 6. Test functions, simulation
(( 11 integrated test signal generators can be activated via control (front panel or computer connection):
((
1]
Via control (front panel or computer connection) values ((
)) can be simulated on the main processor NZ 12.
Simulation values can also be specified for (( 1] outputs via control.
The specification of simulation values or the activation of test stages via the control field is only possible if the binary input named 'test approval' is active.
Author: MUller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 16 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250
- 7. Monitoring Monitoring of the measuring channel [] is performed by the main processor. If a defect is recognised by the main processor, the measuring channel remains functional and a group alarm is generated by the main processor:
))
7.1 Monitoring of (( )) I/0 processor 1]
7.2 Monitoring of the (( 1] processor 11 Author: Muller/EKS-M No.: 5-0106 D1OE Edition: 2 of 29.01.88 Page: 17 of 18
Non-proprietary Version Functional specification for the Digital Wide Range Channel DWK 250 7.3 Monitoring of high voltage and operating voltage The detector high voltage and (( )) voltages are cyclically monitored for deviations by the main processor.
7.4 Monitoring of the recursive filter
((
11 Author: Miller/EKS-M No.: 5-0106 DIOE Edition: 2 of 29.01.88 Page: 18 of 18
/0 Ir--o0-Non-proprietary Version MGPU-&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany This is a non-proprietary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( 1]
Technical Information Digital Measuring System TK 250 Wide Range Preamplifier TKV 23 Contents Features and Applications Description Functional diagram Plug pin allocation Technical data Main dimensions Ordering information Features
- Preamplifier for fission chambers
- Pulse output for start-up range
- Alternate current output for intermediate range
- Signal for high voltage monitoring
- 500 or 750 line driver for long cable lengths
- Stable HF- proofed brass housing Application The wide range preamplifier is used for incore neutron flux instrumentation together with a detector for startup range and intermediate range and for connection to the digital wide range channel DWK 250.
Edition 4 / 20.05.97 Page 1 of 6 Doc.-No. 5-0009 V1 OE
Technical Information Non-proprietary Version Wide Range Preamplifier TKV 23 Description The wide range preamplifier in its first stage amplifies the measuring signal obtained from fission chamber and derives through a wide band post amplifier the pulse signal for the startup range. A second narrow band post amplifier delivers the alternate current signal for the intermediate range.
The digital wide range channel supplies the wide range preamplifier with the electrical energy and high voltage. The function of the preamplifier with two built-in remote controlable test levels can be checked from the digital measuring channel.
The input resistance can be adjusted for cables of 50 to 75!G characteristic impedance. An impedance of 50 to 75k) is also possible for the output impedance. The standard for all impedances is 500.
The wide range preamplifier is built in massive brass housing to protect from electro-magnetic interference waves. An insulated installation in an additional housing, which has been designed according to the plant specific conditions and connected to protective voltage, is strongly advised. Due to the high amplification and large band width of the wide range preamplifier, it is further necessary to use super- screened coaxial cables to connect the detector.
The variant design TKV 23.21 is applicable for high sensitive fission chambers with an high voltage up to 800V. It has an additional input filter to divert the high voltage peaks at the detector input. The operating resistance is reduced for detector currents up to 30mA D. C.
Further the alternate current sensitivity is reduced.
Functional diagram Edition 4/20.05.97 Page 2 of 6 No.: 5-0009 Vl10
Technical Information Non-proprietary Version Wide Range Preamplifier TKV 23 Plug pin allocation 11 Plug pin allocation Han 7D for power supply and control signals
((
11
((
1]
') Designation of connectors changes according to cable entry Edition Page 3 of 6 No.: 5-0009 V1O Edition 4/20.05.97 4/20.05.97 Page 3 of 6 No.: 5-0009 V10
Non-proprietary Version Technical Information Wide Range Preamplifier TKV 23 Technical Data TK 250 Standard data see Data sheet 25 438 D09 High voltage section TKV 23.11 TKV 23.21
))
Input Input resistance 50 0; 75 0 possible Alternate current amplifier Output resistance 500 750
((
11 4/20.05.97 Edition 4/20.05.97 Page 4 of 6 No.: 5-0009 V1O Edition Page 4 of 6 No.: 5-0009 V10
Technical Information Non-proprietary Version Wide Range Preamplifier TKV 23
[R Pulse amplifier 1]
Output resistance TKV 23.11 500, 75(2 possible TKV 23.21 75fl, 500 possible 11 Test levels
))
Climatic stress
((
11 Mechanical Stress
((
11 Power supply 11 Edition 4/20.05.97 Page 5 of 6 No.: 5-0009 Vl0
Non-proprietary Version Technical Information Wide Range Preamplifier TKV 23 General data Housing brass, nickel-plating Dimensions approx. 268 x 155 x 53 mm Mass approx. 4 kg Main Dimensions zs, Ir 11 M \
'0 ~0 H E w~ I DargcsteIlte Variance: TKV 23.11 Displayed variant: TKV 23.11 Ordering information TKV 23.11 Wide range preamplifier 1 1V/pA 25592-4-0353796 TKV 23.21 Wide range preamplifier 1.OV/pA 25592-4-0353940 The ordering data should be supplemented by information on requirements for high voltage monitoring, test frequencies, cable impedance and cable diameter.
Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Muenchen Fax: +49 (0)89 51513-169 I-Examin. of contents: Author: Rg / GVK-M No.: 5-0009 VIO Formal releasement : . Edit.: 4 / 20.05.97 Page: 6 of 6 4TAV23E.DOC
Non-.oropnebtary vembn Al I-r-06 initui (Mbode Gre&).
an has bemr ranxued ac*orfth In 0"is dor*u to 10 CFR 2.398 eMcueons Nheuclead M ,
H&B) GmbH MG OB prop.,,=..t,=,anareot.,..by.
twockm ,*=,mo,,,,~h=ff 1]
.o.f,* Mirion Measurement (MGPI NuclearTechnologies
- Munich, Germany List of eciApment qualification (Translation from original document "Verzeichnis typgeprOfter Komponenten", doc. No. 25 438 Q10)
- 1. Detectors Certifying Project/ No.
Type Authority Qualif. Basis Date Certificate No. Doc.
TOV-Rheinland K'A 3505 064 KB 100 PEF 19.04.95 T-01 03/95A KB 100 SEF TUV-Rheinland M~hlh.KalI. 29.11.85 R63-1101/85 035 KG 50 SEC TUV-Nord IEEE 323 1012006 ETS1/KG50SEC_1 087(125)
KG 80 RW-TUV-Essen THTR 07.05.85 25023f79 F300 038 KG80 KG 80 PEF TOV-Rheinland KTA 3505 19.04.95 T-01 03/95A 064 KG 82 SEZ TOV-Rheinland M~hIh.Kgrd. 25.11.87 R63-22.30 031 KG 83 SEZ TOV-Bayern KKG 17.07.85 KSS50/05/85 006 KG 122 PEF TOV-Rheinland KTA3505 19.04.95 T-01 03/95A 064 KG 151 RBF H&B Analogie 24.11.93 6-7014 B21 005/005b A KG 151 REGIZ TUV-Bayem KKG 25.03.85 KSS50/03/85 005/005a+041 KG 151 REK TOV-Bayern 31.05.83 25023/82 F300 010 KG 220 EEM H&B Analogie 02.10.97 5-0067 Q01 Z,A KG 220 SEF TUV-Bayern KTA 1501 14.11.86 KSS50/01/86 015+041 KG 220 SEU TOV-Bayem KRB B/C 17.12.84 KSS50/001/84 014+068 TKS 01 TOV-Bayern KKG 17.07.85 KSS50/05/85 006(5)
KNK 50 H&B Betr.Bew.Nw. 26.01.84 25054/83 A KNK 50 SAC T.V-Bayern KTA 3505 09.02.88 KSY50/121/86 034 KNK 52 TUV-RhId./PTB KFA-Julich 16.09.92 T17-0904/92 060 KNK80 RW-TOV-Essen THTR 07.05.85 25023/79 F300 038 KNK80 KNK 81 RW-TOV-Essen THTR 06.05.85 25023/79 F300 038 KNK81 KNU 50 TOV-Rheinland KTA 3505 10.10.86 R63-1001/86 036 SB 40 TOV-Bayern KKK 25.03.85 KSS/02/85 007+068 SB 150 TUV-Bayern KKG 25.07.83 KSS50/001183 004+068 SG 65 M/M-F TOV-Bayem KKK 22.07.85 KSS5O/04/85 008+068 SG 65 M-A T."V-By/Analogie allgem. 21.02.95 QNW-SG65M-A 068+008 SG 65 M/-F/-A TUV-Nord erg.Prfg. WB 26 01/2002 SG65M_012002 086 SG 66 RW-TOV-Essen SNR300 1.) 01.12.93 2.7.6-1/93 029 KTA3505 2.) 18.03.94 2.7.6-1/94 029 KTA3505 3.) 13.06.05 Nachtr. zu 2.7.6-1/93+/94 029 ZG 50 A1...4 TOV-Nord WB 26 07/93 1220161921/001 049 Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmBH D- 80687 MUnchen Fax: +49 (0)89 51513-169 Examin. of contents:l/1 Author: MGPI-DOC, FSI Doc-No. 25438-Q10E Formal release: 4 Page 1 of 5 Edition 3 / 29.04.2014 E-1410060
Non-proprietaryversion List of equipment qualification
- 2. RMS Monitors Certifying Project/ No.
Type Authority Qualif. Basis Date Certificate No. Doc.
AD 20 TOV-Nord WB 26 22.02.91 1225070706/001 058 AD 24/25 TOV-Nord WB 26 09/2003 ADAG24 0903/01 078b AG 24 TOV-Nord WB 26 09J2003 ADAG24 0903/01 075b FAIFG 41 Nachqu. TOV-Nord WB 26 09/2003 ADAG24 0903/01 075b+078b FAIJ 60, FAIJ61 TUV-SOdd WB 26 10.10.97 ETS 10/01/971Sche 076 FA/J51 SG TOV-Nord WB 26 (KTA1503.2) 0512001 01895007290/Rev. 1 083 JD 24 (FJ41 +DEK) TOV-Nord KTA 1505 0312004 ETS1/03.04_0 (077+) 092
- 3. Moduls (Electronic Boards)
Certifying Project/ No.
Type Authority Qualif. Basis Date Certificate No. Doc.
[1 1]
Edition 3 / 29.04.2014 Page 2 of 5 Doc-No. 25 438-Ql0E
Non-proprietary version List of equipment qualification
((
1]
- 4. Pre-Amplifiers, Signal Convertors Certifying Project/ No.
Type Authority Qualif. Basis Date Certificate No. Doe.
NV 101 TU V-Nord KTA 3505 08/97 175509767H/002 080 NV 102, NV 102P TO V-Nord KTA 3505 04/2007 NQ TK250 Bgr.042007 050+112a NV 102, NV 102H TOV-Nord KTA 3505 04/2007 NQ TK250 Bgr.042007 070+112a NV 102.x TUV-Nord KTA 3505+1505 03/2010 ETS11SON20090653_1 099a+123a NV 103.x TUV-Nord KTA 3505+1505 03/2010 ETS11SON2009/0653_2 099b+123b NV102.20-/5-8521 TOV-Nord KTA 3505 06/2009 ETS1ISON2009/0070_3 099c NV 320.41/5-8032 H&B (for Doel) IEEE-323 21.05.96 5-8032 Q30E 079 TKV 23 T0V-Rheinland KTA 3505 11.11.87 KWW-1101/87 039+065 TKV 32 RW-TUV-Essen KTA-Vorl. 21.12.82 IV.3,1.2-7/82 A-THTR
- 5. Measurement Channels Certifying Project/ No.
TvDe Authority Qualif. Basis Date Certificate No. Doc.
DAK 250/SW (VI) TUV-Nord KTA 3505 06/95 01225286853/001 069 DAK 250/Ges.(V1) TUV-Rheinland KTA 3505 30.06.95 T1 7-0601/95 070 DAK 250-g/SW(V2) TUV-Nord KTA 3505 11/2002 ELT. 03.006.01/002 089 DAK 250-glGes. (V2) (TUV-Nord) KTA 3505 12/2002 5-0285 L41 090 DAK 250/SW TOV-Nord IEC 60880 09/2010 DAK250-TN2010/3-476A-PZ 127 DAK 250/SW TOV-Nord KTA 3503/3505 08.08.12 DAK-TN2012/01-525A-AC 128a IEC 60880 DFK 251/SW TOV-Rheinland WB-26 06.06.90 T-0606/90 053 DEK 251/SW TOV-Nord KTA3SO3NWB26 03/2001 01225299190 084 DEK 251/Ges. TOV-Nord WB 26(KTAIS03.2) 05/2001 01 895007290/Rev. 1 083 DGK 250/SW+Ges. TOV-Nord KTA 3505 07/96 01225292163/001 074 DGK 250/SW V2 TU V-Nord KTA 3505 19.04.07 DGK250-TN2007/1-507A 103 DGK 250/SW V3 TUV-Nord KTA 3505 30.07.09 DGK250-TN2009/3-513B 120 DGK 250 M TUV-Nord KTA 3505, 11.06.10 DGK250-TN2010/1-517A-PZ 124 DGK 250/SW TOV-Nord KTA 3503/2505 14.08.12 DGK250-TN2012/O2-529A-AC 128b IEC 60880 Edition 3 / 29.04.2014 Page 3 of 5 Doc-No. 25 438-QIOE
Non-propAetary version List of equipment qualification DLK 250/SW TUV-Nord KTA 3505 9.5.07 DLK250-TN2007/1-494A 110b DLK 250/Ges. TUJV-Nord KTA 3505 04/2007 DLK250 042007 110a DMK 250/SW V1 TU V-Nord KTA 3505 16.09.92 122507221/002 063 DMK 250/SW V2 TCJV-Nord KTA 3505 14.10.93 1225279936/002 063a DMK 250/SW V3 TOV-Nord KTA 3505 12/2005 M.ETL03.006.02/003 063b DMK 250/Ges. TUV-Rheinland KTA 3505 09.09.92 T1 7-0903/92 062 DPK 250 TUV-Rheinland WB-26 08.08.88 T-0801/88 040 DPK 251/SW TUV-Rheinland WB-26 07.09.89 T-0801/89 047 DSK 250/SW V1 TUV-Rheinland KTA 3505 08.07.91 945/K72401/91 046 DSK 250/SW V2 TOV-Rheinland KTA 3501 21.10.93 945/K727/93 046a DSK 250/Ges. TOV-Rheinland KTA 3505 09.09.92 T17-0902/92 061 DWK 250/SW TCJV-Nord KTA 3505 16.08.90 1225068496/01 048 DWK 250/Ges. TOV-Rheinland KTA 3505 15.01.91 T-0101/91 059
- 6. Computer Software Certifying Project/ No.
Tvoe Authority Qualif. Basis Date Certificate No. Doc.
[II
))
- 7. Qualification Evidence for TK 250 Modules Certifying Project/ No.
Type Authority Qualif. Basis Date Certificate No. Doc.
[II
))
Edition 3 / 29.04.2014 Page 4 of 5 Doc-No. 25 438-Ql0E
Non-proprietary version List of equipment qualification
- 8. TK 240 Modules Certifying Project/ No.
Tvoe Authoritv Qualif. Basis Date Certificate No. Doc.
j ~~ ~ ~
i........ ~ u lf Basis.
TKKG 11.51/61 TUV-SOdwest i.Anl. KTA 3503 20.06.90 5-0152 B03 052 TKKG 12.51 TUV-Sidwest i.Ani. KTA 3503 20.06.90 5-0152 B03 052 TKKG 13.51 TUV-Sadwest i.Anl. KTA 3503 20.06.90 5-0152 B03 052 TKKG 14.51 TUV-Nordd. KTA 3503 01.04.82 6-7206 F30 002 TKKU 11.5x TUV-Nordd. KTA 3503 01.04.82 6-7373 F30 003
- 9. Accessories Certifying Project/ No.
Type Authority Qualif. Basis Date Certificate No. Doc.
Mi. Kabel 1ZsAcCAc40 TUV SOD KTA 3505 Febr.2009 T12-09-ETL001 119 Trennverst. NT69 TUV Nord KTA 3505 f. KKU 06/2005 NT69.11 062005 93b Netzfilter )
0872 733 ) H&B Betr. Bew. 18.05.92 0872733 Q01 Z,A 0805 905 DOLD-Regler DDN45-E-P-2P, Pumpe VT4.40 TOV-NORD KKK-Jodmonitor Okt.2007 ETS1/H1388 KKK 1 a 094 Neubg. Membranpumpe TOV-Nord KTA 1503/1505 05/2007 PM21 Pumpen 04105.2007 114 DOLD-Regler DDN45-E-P-2P, DDN46-E-Z-2P, DOLD Halbleiterschetz BF 9250/0_2 TUV-NORD s.Bericht Juni 2009 ETS1/SON20080392_1 117 Abbreviations: A = Archive AWM E = Design & Development Z = Drawing Storage ZWM DMS = Document management system Page 5of5 Doc-No. 25 438-Qi QE Edition 3/29.04.2014 Edition 3 / 29.04.2014 Page 5 of 5 Doc-No. 25 438-Ql OE
A44T-r-0 7 Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun File: <hub5.tk250>qsmunuaL.txd,Translatedfrom German to Englishon 2013-02-14 on from which the proprietary information has been remove d according to 10 CFR 2.390.
In this document the remo*ved sections of proprietary I information are indicated by t wo opening and two closing This is a non-proprietary brackets as shown here: versi
(( ))
Digital Radiation Monitoring System TK250 QUALITY ASSURANCE IN THE SOFTWARE DEVELOPMENT Manual Forwarding and reproduction of this documentation, utilisation and notification of its content is not permitted, unless consent is explicitly granted. Violations will lead to claims for compensation.All rights are reserved where a patent is grantedor an invention registered.
Author: Mtiller / EKS-M Page: 1 of 10 Edition: 1 of 14.01.88 Doc.No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun Table of contents Introduction 3 Software development process 3 General design principles 4 Design of module interfaces 4 Parallel processes, multitasking 5 File name convention 6 Organisational structure of the software documentation 7 SUBMIT files 7 Source program files 8 INCLUDE files 8 Other files 8 Description of program modules 8 File header information for source program modules 9 Version monitoring 10 Other measures 10 Author: MWiller / EKS-M , Page: 2 of 10 Edition: 1 of 14.01.88 Doc.No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun Introduction This manual contains a range of development guidelines especially for the TK 250 system, compliance with which should ensure the creation of high quality software. The aim of this manual is not to describe procedures and principles about which there is a general consensus and proficiency in which can be expected from a software developer.
This manual is a binding convention within the company. However, deviations can be made in justified cases. Outside of the company, the purpose of this manual is to make the software development process transparent.
Software development process The basis for the software to be developed is a set of specifications jointly developed and adopted by the bodies involved. In the subsequent conceptual phase, the outlay (CPU load, memory use, staff costs) is assessed, modularisation is developed and a viability study is conducted for particularly critical software sectors.
In the module hierarchy, the development sequence of individual software modules is from bottom to top. The software is integrated inline also from bottom to top and a suitable test environment is applied to the last module added in each instance where necessary.
The project manager hands over the individual planned program modules to the project employees for processing and receives the finished program modules for integration.
The specification for the development of a module is its conception, especially the definition of its interface. In parallel to the development of a module, after its completion at the latest, the relevant documentation is drafted. A software module is only considered complete if the relevant documentation is available.
Tests only take place within the development team for the purpose of proving the quality of the completed module to the extent that the further course of the project is not endangered by inferior quality software (module test in accordance with WN 261-501 or integration test in accordance with WN 261-505). This cannot and should not replace independent software testing (either in-house or outside of the company). Whether testing takes place on an ad hoc basis or whether the tests are planned and documented is decided according to the cost/benefit ratio of the tests.
Author: MLiller/ EKS-M _ Page: 3 of 10 Edition: 1 of 14.01.88 ,, Doc.No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun General design principles The following criteria are very important for the software to be created:
- Simplicity and comprehensibility
- Reliability
- Efficiency
- Adaptability and general usability Efficiency with regard to memory use is of special significance for the TK250 processor modules due to the hard address space restrictions of (( 1] architecture.
Starting from the statement of task, the software is appropriately modularised, whereby the following aspects are taken into consideration in particular:
- Top down development, principle of gradual refinement, abstract (virtual) machines
- Information hiding (separation of module interface and implementation of the module).
- At the highest level, modularisation by division into tasks running in parallel Depending on requirements, modules are implemented in (( )) or in the higher programming language (( )) whereby the rules of the structured programming are complied with.
Design of module interfaces In principle, the (( 1] enables automatic transmission of parameters when procedures are called.
Nevertheless as the procedural parameters occupy space in the very small internal RAM, use of this mechanism is prohibited for larger software systems.
Instead, a data interface is defined in addition to the now parameter less procedure call interface. This separate data interface holds the input and output parameters during procedure calls and parameter values must be explicitly written to it or read from it.
In order to increase comprehensibility, long, informative names are selected, whereby all names of a module interface (names of procedures, names of data interfaces) have an identical prefix.
With regard to the method of action, this procedure is equivalent to the customary procedure of parameter transmission (e.g. named parameters in ADA).
Author: M~aller / EKS-M ' -1 Page: 4of 10 Edition: 1 of 14.01.88 '*' Doc.No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun Parallel processes, multitasking Where required by the statement of task with regard to parallel processing and reaction time, the MTX real time operating system core is used. MTX has a very simple and comprehensible design and is small (700 bytes).
The following restrictions increase software reliability and avoid a range of possible problems from the outset:
- No dynamic memory management
- Static task structure (no generation and deletion of tasks during run time).
- Equal priority for all tasks in conjunction with time slice task switching prevents monopolisation of the CPU by tasks and simplifies the estimation of response times
- Only 1 interrupt source: timer for time management and time slice switchover.
- Hierarchically ordered critical sections with a predetermined allocation sequence guarantees freedom from deadlocks.
The architecture of (( 11 in conjunction with the (( )) is not supporting re-entrant procedures.
Therefore data to which parallel processes have concurrent access are generally assigned to a critical section (named REGION) together with their associated access procedures. This approach ensures a serialization of the task access to the protected data. This corresponds to the 'monitor concept' according to Hoare and Brinch Hansen.
Author: M6ller / EKS-M Page: 5 of 10 Edition: 1 of 14.01.88 Doc. No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun
[1 1]
Author: Miller / EKS-M c6?zt a oy Page:
6 of 10 Edition: 1 of 14.01.88 £4 Doc. No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun Oreanisational structure of the software documentation An organisational structure is defined for all files within a software project. This structure is expressed in a relevant file name convention.
This organisational structure can be used both for ongoing software development projects and also for completed projects (archived software packages).
At the highest level, the software of a device is subdivided into the software packages assigned to the individual processors. These software packages are archived under separate identification numbers. The correlation of the individual software packages is documented in the channel construction set.
((1
))
Author: Miller / EKS-M Aft Page: 7 of 10
(~ Doc.No.:
Edition: 1 of 14.01.88 £4 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun Source code files All source code files can be identified by their file names:
(( 1]
INCLUDE files All include files can be identified by the file name:
[ 1))
Modules define their interface for USING modules with the aid of an include file which contains the declarations necessary for the use of the interface. This mechanism reproduces the separation of definition and implementation introduced in the MODULA and ADA languages.
Other files The (( )) contains the EPROM image for the EPROM programming device.
A textual description is assigned to each module in the (( )) file.
Description of program modules The starting point for implementing a program module is the specification of the program module which contains in particular the definition of the interface and the function of the program module.
A description (actual) is derived from the specification (target) when a program module is implemented.
This constitutes, linguistically-speaking, a higher quality and super ordinate description as a supplement to the program text. Information contained in the program text anyway should not be redundantly repeated at the same language level but higher quality linguistic devices should be applied and ADDITIONAL information is conveyed:
- Natural language
- Graphic representations
- Task diagrams
- Pseudocode
- Nassi-Shneidermann diagrams (Program process schedules should only be viewed as sensible representation techniques in exceptional cases)
- Finite state machines
- Petri networks
- Layer models
- Data flow diagrams etc.
Author: MUller / EKS-M ,[' f*, Page: 8 of 10 Edition: 1 of 14.01.88
- Doc.No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun File header information for source program modules Every program module contains a program header with the following entries:
))
These entries are also included in the file name of the program module in compressed form and are repeated in full form in the program header. In addition, the program header contains entries for:
((
1]
Then, an amendment list follows in the program header which records all changes made since approval of the module. An entry exists for each change which comprises the following components:
[1]
Author: Mfiller / EKS-M 1141 Page: 9 of 10 Edition: 1 of 14.01.88 Doc. No.: 0348548E
Non-proprietary Version Manual for quality assurance in software development Hartmann & Braun Version monitoring a) Current project Within a current project, the version identification designated for file names in accordance with the file name convention enables version monitoring.
A version identification exists both for each program module and also for the software system of a processor. The version identification of the software system is contained in the (( )) files and must be identical for these files.
The version identification for the software system and the version identifications of the individual modules are independent of one another:
A version 0 system can definitely contain advanced module versions or A system with advanced version identification can contain version 0 modules.
b) Completed project A software package is identified by an identification number and is archived under this identification number on a data medium (( ))
A software package thus archived is complete in all modules and inherently autonomous.
If a new version of a software package needs to be created, the software package is completely loaded into the development system, edited there and finally the new version is archived.
Although this procedure potentially leads to retaining multiple copies of identical software modules, it prevents unforeseen long-distance effects of changes and supplies self-contained documentation.
Other measures As one of the weaknesses of (( 11 programming languages lies in the area of syntax, a syntax based on the ADA language is introduced for monitoring structures (( )) with the aid of LITERALLY declarations. The readability of the programs is thus improved somewhat.
The EPROM or the EPROM set of a processor module contains the identification number in ASCII format starting from address 26H.
At the end of the software development process, a stack calculation is used to prove that the occurrence of a stack overflow is precluded.
Author: Mbller / EKS-M ,. Page: 10 of 10 Edition: 1 of 14.01.88 Doc.No.: 0348548E
A14?F-CS&0 Non-proprietary Version a
MGP IOsB Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany This is a non-proprietary version from which the proprietary Information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two dosing brackets as shown here: i[ B Generic Software Quality Assurance Plan Digital nuclear measurement system TK 250 Copyright 2013. Mirion Technologies (MGPI H&B) GmbH All rights. including rights patent and registered-design rights, where applicable, reserved. Transmittal, reproduction, or utilization of this document or disclosure of its contents without expressed authorization by the copyright holder are prohibited. Violators shall be held liable for damages.
Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Manchen Fax: +49 (0)89 51513-169 Examin. of contents: CnA" Author: MGPI-SW, TBe, Ter 7 "e Doc-No. 0348 664 A60E Formal release: Page 1 of 29 Edition 4 12013-02-18 Itteilung E-1310058 SQA*.QAPZE'dition 4AlSoftware File: Y:\TlQASO Quality Assurance Ran 0348664 A,*0EedWidocx
Non-proprietary Version Software quality assurance plan (SQAP)
List of Revisions Revision Date Scope of Revision Section page 2010-09-17 First edition all Reference /2.11/ has been removed from this document and thus hapter reference /2.12/ has been renamed to /2.11/. The corresponding 2.1.2,8.1 references in the document have been updated.
2 2010-11-09 The entry criteria of the development phases have been updated. Chapter 3.2 Error correction: In the previous edition "Phase VII" was listed Chapter twice, while "Phase VIII" was not listed at all. In the new edition Cat both phases are now listed. 8.1 Changes after TUV review: "Manufacture" replaced by Chapter "Implementation" 1.2 Changes after TUV review: Correction of spelling mistake Chapter 2.1.1 Changes after TUV review: Enhancement of exit criteria in Chapter subchapters 5 with list of modifications; in subchapter 6, 7, 8,11 3.2.ff with test plans 3 2010-11-24 Changes after TOV review: Update of V-model (fig. 2) Chapter 5
Changes after T0V review: Small improvements in this chapter.
Adding additional tools for code analyses from MGPI and from Chapter TUV Update of figure 1, TOV is shown as external organisation Chapter
___3.1 Label of figure 3 changed to "MGPI internal approval of a Chapter document" 6 4 2 References in chapter 2.1 translated into English. Reference Chapter
/2.3/ corrected to 10 CFR 50 App. B 2.1 of 29 Doc.-No.: 0348 664 A6OE Edition: 4 // 2013-02-18 Edition: 4 2013-02-18 Page 2 Page 2 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
Table of contents 1.I Introduction ............................................................................................................................. 5 1.1. Purpose ............................................................................................................................... 5 1.2. Scope .................................................................................................................................. 5
- 2. References, Abbreviations and Acronym s ......................................................................... 6 2.1. References .......................................................................................................................... 6 2.1.1. MG PI internal documents .......................................................................................... 6 2.1.2. General quality procedures and instructions .............................................................. 6 2.2. Abbreviations and Acronym s ........................................................................................... 7
- 3. Management ............................................................................................................................ 8 3.1. Organization ........................................................................................................................ 8 3.2. Tasks .................................................................................................................................. 9 3.2.1. Phase I: System requirem ents specification .............................................................. 10 3.2.2. Phase II: Software requirements specification ......................................................... 10 3.2.3. Phase II: Software design specification .................................................................... 10 3.2.4. Phase IV: Module specification .................................................................................. 10 3.2.5. Phase V: Implementation ........................................................................................... 10 3.2.6. Phase VI: Testing .......................................................................................................... 11 3.2.7. Phase VII: Integration ............................................................................................... 11 3.2.8. Phase VIII: Validation ............................................................................................... 11 3.2.9. Specification of the EPRO M parameter settings ........................................................ 12 3.2.10. Im plementation of the EPROM parameter settings ................................................... 12 3.2.11. Verification and validation of the of the EPROM parameter settings ......................... 12 3.2.12. Company internal transfer of the software from development to production ............... 13 3.2.13. Installation ..................................................................................................................... 13 3.2.14. Com missioning .............................................................................................................. 14 3.2.15. Operation and maintenance ..................................................................................... 14 3.3. Roles and responsibilities ............................................................................................. 15
- 4. Docum entation ...................................................................................................................... 15 4.1. Purpose ............................................................................................................................. 15 4.2. M inim um documentation requirem ents ......................................................................... 15 4.2.1. Project development plan (PDP) ................................................................................ 15 4.2.2. Software requirement specification (SRS) ................................................................ 15 4.2.3. Software design description (SDD) ........................................................................... 16 4.2.4. Verification and validation plan and result reports (SW P) ........................................ 16 4.2.5. User docum entation ................................................................................................ 16 4.2.6. Software configuration management plan (SCM P) ................................................... 16 4.2.7. Project specific traceability matrix (PTM) .................................................................. 17 4.2.8. Requirement traceability matrix (RTM) .................................................................... 17
- 5. Standards, practices, conventions and metrics ................................................................. 17 5.1. Documentation standards ............................................................................................. 19 5.2. Requirem ents standards .............................................................................................. 19 5.3. Design standards .............................................................................................................. 19 5.4. Coding standards .............................................................................................................. 19 5.5. Testing standards .............................................................................................................. 19 5.6. CM standards .................................................................................................................... 20 5.7. Compliance monitoring ................................................................................................. 20 5.8. Meeting procedures ........................................................................................................... 20 5.9. Metrics .............................................................................................................................. 20
- 6. Software reviews ................................................................................................................... 20 6.1. Software requirement specification review ................................................................... 22 6.2. Software design review ................................................................................................. 22 Edition: 4 / 2013-02-18 Page 3 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 6.3. Module specification review ......................................................................................... 22 6.4. Verification and validation plan review .......................................................................... 23 6.5. Functional audit ................................................................................................................. 23 6.6. In-process audit ................................................................................................................. 23 6.7. Post implementation review ........................................... 24 6.8. Software configuration managem ent review ................................................................. 24 6.8.1. Review of software modules .................................................................................... 24 6.8.2. Review of HEX output file ........................................................................................ 24 6.9. External Reviews ............................................................................................................... 25
- 7. Test ....................................................................................................................................... 25
- 8. Problem reporting and corrective action ................................................................................ 25 8.1. Problem handling during software developm ent phases ............................................... 25 8.2. Problem handling for delivered software ....................................................................... 26
- 9. Tools, techniques and methodologies ............................................................................. 26
- 10. Media control ..................................................................................................................... 27
- 11. Supplier control ................................................................................................................. 28
- 12. Records collection, maintenance and retention .............................. 28
- 13. Training .............................................................................................................................. 28
- 14. Risk m anagement ............................................................................................................. 28 14.1. Schedule control ................................................................................................................ 28 14.2. Requirem ent control .......................................................................................................... 29
- 15. G lossary ............................................................................................................................ 29
- 16. SQAP change procedure ............................................................................................. 29 List of figures Fig. 1 Project organization ...................................................................................................... 8 Fig. 2 Software Life Cycle (developm ent) ...................................................................................... 18 Fig. 3 MG PI internal approval of a docum ent ........................................................................... 21 2013-02-18 Page 4 of 29 Doc.-No.: 0348 664 A6OE Edition: 4 4 // 2013-02-18 *Page 4 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
- 1. Introduction 1.1. Purpose The purpose of this software quality assurance plan (SOAP) is to describe and define the procedures used during the software development process for the TK250. systems and to assure the quality of the product to be delivered.
The SOAP identifies the documentation to be prepared during the development, verification, validation, use, and maintenance of the software product.
The SOAP describes the organizational elements, responsible for the origination, verification, validation, maintenance, and control of the required documentation.
It also identifies the specific reviews, audits, and the associated criteria required for each step of that portion of the software lifecycle covered by the SOAP. In particular, it identifies the key documents to be reviewed during the management and monitoring reviews.
The format of this SQAP is compliant to IEEE 730 standard, ref. to /2.9/ and complies with all demands from the IEC 60880, §5.5, ref. to /2.5/.
1.2. Scope The product portfolio of Mirion Technologies (MGPI H&B) GmbH is subdivided into radiation monitoring and neutron flux monitoring systems. They consist of detectors and a modular TK250 electronic board system. In these measuring systems microcontroller boards are used for signal processing purposes (for example: NZ 21, NZ 12 and NK 21). These boards are equipped with application specific software (firmware).
This software quality assurance plan applies to the software of those TK 250 systems (channels),
which are designed for the use in IEC 61226 category A or 1E applications. It is thus applicable for the software of the following neutron flux monitoring channels and variations of these channels:
DAK 250, DGK 250, DWK 250, DMK 250, DSK 250, DLK 250.
In this SOAP dedicated development, test, documentation and management activities are described. They shall be applied to the aforementioned software, its development process and the tools used in the development process.
This SQAP covers the following phases of the software life cycle:
> Specification
> Design
> Implementation
>V&V
> Installation
> Commissioning o Operation and maintenance Doc.-No.: 0348 664 A6OE Edition: 4 2013-02-18 4 // 2013-02-18 Page 5 Page of 29 5 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
- 2. References, Abbreviations and Acronyms 2.1. References 2.1.1. MGPI internal documents
/1.1/ Quality management manual (QMM) Doc.-No. 0348 250E ed7
/1.2/ Process description Doc.-No. 0348 250 B20E ed4 11.3/ Requirements and procedures for Class-1 E-Equipment Doc.-No. 0348 591 A50E edl
/1.4/ Requirements for technical documentation Doc.-No. 0348 585 A6E ed2
/1.5/ Guidelines and rules for the software archive Doc.-No. 0348 074 A61Eed2
/1.6/ Software configuration management plan (SCMP) Doc.-No. 0348 665 A60E ed2
/1.7/ Software coding rules and standards for TK 250 Doc-No. 0348 662 A60E ed2
/1.8/ Code review check list for TK 250 software Doc-No. 0348 662 L60E edl
/1.9/ Control of documents and records Doc-No. 0348 250 B20E edl
/1.10/ Failure statistics for modules and detector systems Doc-No. 0348 089 A06E ed3
/1.11/ Software handover protocol Doc-No. 0348 121E
/1.12/ Procedure for tracking software defects Doc-No. 0348 663 A60E edl
/1.13/ EPROM for TK 250 Doc-No. 5-1105E ed3
/1.14/ Procedure for handling customer complaints Doc-No. 0348 605 A12E edl 2.1.2. General quality procedures and instructions
/2.1/ Quality managements systems - requirements DIN EN ISO 9001-2008
/2.2/ Quality assurance requirements KTA 1401 - 1996 12.31 NRC Regulations (Nuclear Regulations) 10 CFR 50 App. B
/2.4/ IEEE Standard for Software Configuration Management IEEE Std. 8 2 8 TM - 2005
/2.5/ IEC Standard for software in nuclear power plants IEC 60880:2009
/2.61 IEEE Recommended Practice for SRS IEEE Std. 8 3 0 TM - 1998
/2.7/ IEEE Standard-Systems Design-SDD IEEE Std. 1 0 1 6 TM -2009
/2.81 IEEE Standard for Software Verification and Validation IEEE Std. 1 0 1 2 TM - 2 0 0 4
/2.9/ IEEE Standard for Software Quality Assurance Plans IEEE Std. 7 3 0 TM - 2002
/2.10/ IEC Standard for classification of instrumentation IEC 61226:2009
/2.11/ IEEE Standard for Software Test Documentation IEEE Std. 8 2 9 TM - 2008 2013-02-18 Page 6 of 29 Doc.-No.: 0348 664 A6OE Edition: 44 // 2013-02-18 Ediltion: Page 6 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 2.2. Abbreviations and Acronyms AAW Work instruction AR Anomaly report CCB Configuration control board Cl Configuration item CM Configuration management MGPI Mirion Technologies (MGPI H&B) GmbH (manufacturer / supplier)
NFL Neutron flux ,
OAW Organization instruction PDP Project development plan PTM Project specific traceability matrix QA Quality assurance QAP Quality assurance plan QMM Quality management manual QMS Quality management system RTM Requirement traceability matrix SCM Software configuration management SCMP Software configuration management plan SDD Software detailed design SRS Software requirement specification SQA Software quality assurance SWP Software verification and validation plan TOV Technischer Uberwachungsverein VAW MGPI process instruction (Verfahrens-Anweisung) 29 Doc.-No.: 0348 664 A6OE Edition: 44 /I 2013-02-18 Edition: 2013-02-18 Page 7 Page 7 of of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
- 3. Management 3.1. Organization The complete and current organization of the Mirion Technologies (MGPI H&B) GmbH is shown in the company organization chart in the QMM, see /1.1/ §2.4.
The organization within a project, the individual responsibilities of the project teams and the team members are described in the Project Development Plan (PDP). The general project structure of a typical software development project is shown below:.
I]
Fig. I Project organization The software development process is embedded in a matrix project organization.
The TOV is involved in the software development process as an external, independent verification and validation team. Additionally there is an independent test team at MGPI. In general the verification and validation activities are carried out by TUV or an engineer from MGPI under supervision from TOV. The responsibilities for the V&V tasks, the test teams and their activities are defined in the project specific PDP. Functional tests may be executed by the TUV or the MGPI internal test team or test responsible.
The Project manager is responsible for the communication with the customer. All managerial or technical requests from or to the customer are linked over the project manager.
Edition: 4 / 2013-02-18 Page 8 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SOAP) 3.2. Tasks Based on the V-Model of IEC 60880 the software development process is divided into 8 different phases (see fig. 2):
I. System requirements specification II. Software requirements specification III. Software design specification IV. Module specification V. Implementation VI. Testing VII. Integration VIII. Validation This SOAP covers all of these phases. In general each phase has to be finished and reviewed before the next phase can be started. The tasks assigned to these phases are described in the following subsections.
As a common design principle the parameters in all TK250 channels are subdivided into two groups:
Group A) Parameters which can be modified by the user or host computer while the system is in operation. These parameters are stored in NVRAMs.
Group B) Parameters which cannot be modified while the system is in operation. These parameters are stored in EPROMs. Thus they are called EPROM parameters.
Because of this design feature the build process for the software (firmware) of a TK 250 channel includes the following EPROM parameter configuration process:
- 1. Specification of the EPROM parameter settings
- 2. Implementation of the EPROM parameter settings
- 3. Verification and validation of the EPROM parameter settings The software development process with its phases I to VIII (see fig. 2) and the EPROM parameter configuration process with the phases 1 to 3 can be omitted in software development projects, if the customers system requirements can be fulfilled without them. If, for example, the customers requirements can be fulfilled by an already existing software containing new application specific EPROM parameter settings, then the project is reduced to the EPROM parameter configuration process and the phases I to VIII of the development process are omitted.
The software build process as described so far results in an EPROM image file (Intel HEX file) for every microcontroller board of the desired TK 250 channel (i.e. NZ 12, NZ21, NK 21).
The installation of the software on these microcontroller boards therefore consists of copying the content of the EPROM image files into the EPROMs of these boards. For this process an EPROM programmer is used.
The commissioning of the software and the related microcontroller boards is based upon the customers system requirements specification and information from MGPI production documents.
For a given TK 250 channel type these documents enlist the hardware and software components that belong to it. Thus they define sets of compatible hard- and software components.
Operation and maintenance of the TK 250 channels and its software (firmware) is governed by the QMM/1.1/.
Edition: . 4 / 2013-02-18 .Page 9 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 3.2.1. Phase 1: System requirements specification The system requirements specification is build by the customer. This document or set of documents contains all customer requirements of the system(s) MGPI has to provide.
3.2.2. Phase II: Software requirements specification Entry criteria: Valid and signed contract and system requirements specification from the customer.
Task: For each software system which has to be delivered to the customer, a software requirements specification (SRS) has to be derived from the system requirements specification. A requirements traceability matrix (RTM) has to be established, to trace the requirements throughout the following development phases. An independent verification team verifies the software requirements specification and creates a verification report.
Exit criteria: Finished and signed software requirements specification and a QA review (end of phase report) with positive assessment results for the SRS, verification report and RTM.
3.2.3. Phase IIl: Software design specification Entry criteria: Valid software requirements specification (SRS) and RTM from phase II Task: The software design has to be specified in this development phase. It has to be checked that all specified software requirements are met by the software design specification (SDS). A independent verification team verifies the SDS and creates an verification report. The requirements traceability matrix has to be updated accordingly. If necessary a software FMEA is executed.
Exit criteria: Finished and signed software design specification and a QA review (end of phase report) with positive assessment results for the SDS, verification report, FMEA and RTM.
3.2.4. Phase IV: Module specification Entry criteria: Software design specification from phase III and traceability matrix.
Task: The module specifications are build according to the software design specification and software requirements specification. They are verified by an independent verification team which creates an verification report. The requirements traceability matrix has to be updated accordingly.
Exit criteria: Complete set of module specifications and a QA review (end of phase report) with positive assessment results for them and for the verification report and RTM.
3.2.5. Phase V: Implementation Entry criteria: Module specifications from phase IVand the traceability matrix.
Edition: 4 1 2013-02-18 Page 10 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SOAP)
Task: In this phase the modules are implemented according to the related specifications from the previous phases. They are verified against the module specifications. The traceability matrix has to be updated accordingly.
In case of a modification of an existing software system, a list of all applied software modifications has to be established.
Exit criteria: Complete set of modules with the new/updated list of applied software modifications and a OA review (end of phase report) with positive assessment results for them and for the code verification report.
3.2.6. Phase VI: Testing Entry criteria: Implemented software modules, module specifications from phase IV and the traceability matrix.
Task: Based upon the specifications from phase IV, module test plans are established.
They describe in detail the test procedures for the module tests. For unchanged and tested modules, which already have been used in previous IEC 61226 category A applications, the module tests can be omitted. In this case the validity of these modules in the new software has to be justified.
The module tests are carried out by an independent test team. The test results are stored in test protocols. Anomaliesare tracked in anomaly reports (see chapter 8) and are resolved.
Exit criteria: Module test plans, module test protocols and a QA review (end of phase report) with positive assessment results for them and for the anomaly handling.
3.2.7. Phase VII: Integration Entry criteria: Complete set of tested software modules, software design specification from phase III and the traceability matrix.
Task: Based upon the software design specification from phase III, the integration test plan is established. It describes in detail the test procedures for the integration tests.
The integration tests are carried out by an independent test team. The test results are stored in test protocols. Anomalies are tracked in anomaly reports (see chapter
- 8) and are resolved.
The user manuals and related product documentation are established.
Exit criteria: Integration test plans, integration test protocols, user manuals and a OA review (end of phase report) with positive assessment results for them and for the anomaly handling.
3.2.8. Phase VIII: Validation Entry criteria: Integrated software system consisting of tested software modules, specifications from the phase II and the traceability matrix.
Edition: 4 / 2013-02-18 Page 11 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
Task: Based upon the specifications from phase II, the validation test plan is established. It describes in detail the test procedures for the validation tests. The validation tests are carried out by an independent test team. The test results are stored in a test protocol and are summarized in a validation report. Anomalies are stored in anomaly reports (see chapter 8) and are resolved.
Exit criteria: Validation test plans, validation test protocol, validation report and a QA review (end of phase report) with positive assessment results for the test protocols, the test report and for the anomaly handling.
3.2.9. Specification of the EPROM parameter settings Entry criteria: Validated software system from phase VIII and the customers system requirements specification. If a translation of the user interface texts into a foreign language is requested, a translated user interface text list is required.
Task: In the first step a interface specification is derived from the system requirements specification. It specifies in a comprehensive form the properties of the analog, binary and digital interfaces between the TK 250 channel and the environment in the customers plant. This specification is send to the customer for approval or a modification of the specifications.
In the next step the specification of the EPROM based parameters is established. It is based upon the system requirements specification and the approved interface specification. If a UI translation is necessary, then the translated UI texts are included into the specification.
A unique identification number (Kxxxx) is assigned to the specified set of EPROM based parameter settings. A project specific configuration process overview and the list of default parameter settings are established.
Exit criteria: Specification of the EPROM based parameter settings.
3.2.10. Implementation of the EPROM parameter settings Entry criteria: Validated software system from phase VIII and the specification of the EPROM based parameter settings.
Task: As described in the SCMP and the configuration process overview a variant of the software system with application specific settings of the EPROM based parameters is build. The original software system (from phase VIII) and the new variant (configured software with unique id number) contain absolute identical program code but do differ in their EPROM parameter settings.
Exit criteria: Software system with application specific settings of the EPROM based parameters.
3.2.11. Verification and validation of the of the EPROM parameter settings Entry criteria: Software system with application specific settings of the EPROM based parameters, Edition: 4 1 2013-02-18 Page 12 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
Software system from phase VIII and the specification of the EPROM based parameter settings. Application specific TK250 channel and wiring diagram for this channel.
Task: A verification and validation plan is established. The verification and validation tests are carried out by an independent test team according to the V&V plan. The results from these tests are stored in a test protocol. A summary of the test results is given in a test report.
Exit criteria: Verified and validated software system with application specific settings of the EPROM based parameters, V&V test plan, V&V test protocol, test report and certificate.
3.2.12. Company internal transfer of the software from development to production Entry criteria: Verified and validated software system; availability of the required software test reports and certificates.
Task: The EPROM image file (Intel HEX file) of the verified and validated software system is given to the test field department. The key properties of this file (i.e. name of the software, name of the microcontroller board, software id number, CRC checksum for the EPROM content, ... ) are documented in a software handover protocol (see
/1.11/). This protocol is given to the test field department along with the EPROM image file.
The test filed manager stores the EPROM image file in his account of the company file server. He verifies the file content (checksum, software identification) notes the verification results in the software handover protocol and gives it to the OA manager.
The QA manager receives the protocol /1.11/from the test field manager. He/she checks its content, assigns a identification number ("Mitteilungs-Nummer'e) to it and distributes a copy of this protocol to the relevant company departments, to notify them about the availability of the new software. The original protocol is kept and stored in the QA department.
Exit criteria: The test field department owns a valid copy of the EPROM image file (Intel HEX file) and is able to install this software on the appropriate TK 250 microcontroller board.
The relevant company departments are notified about the availability of the new software.
3.2.13. Installation Entry criteria: Intel Hex file from a verified and validated software system (see above). EPROM programmer, PC, EPROM, EPROM label, TK250 microcontroller board and a TK 250 channel.
Task: The installation of the software consists of copying the content of the Intel Hex file into an appropriate EPROM. The selection of the EPROM type, microcontroller board type and EPROM label layout are based upon information from the document "EPROM for TK 250" /1.13/ and its associated documents. A PC and a EPROM programmer are used for the EPROM programming process. The EPROM label is then placed on the EPROM, which in turn is mounted on the selected microcontroller Edition: 4 / 2013-02-18 Page 13 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) board. This board and the new EPROM are then tested in a TK 250 channel. This installation process is executed by staff from the test field department.
Exit criteria: Programmed, labelled and successfully tested EPROM on a TK 250 microcontroller board.
3.2.14. Commissioning Entry criteria: TK 250 modules, TK 250 microcontroller boards with installed firmware, system requirements specification Task: The commissioning of the software and the related microcontroller boards is based upon an analysis of the customers system requirements specification and information from MGPI production documents. For a given TK 250 channel these MGPI documents enlist the hardware and software components that belong to it (block diagram, schematic diagram, list of items). Based upon these documents the desired TK 250 channel is assembled. It is then tested by staff from the test field department.
Exit criteria: Assembled and tested TK 250 channel 3.2.16. Operation and maintenance Entry criteria: Transfer of the software from development to production (handover)
Task: Operation and maintenance of the TK 250 channels and its software (firmware) are governed by the QMM /1.1/.
The process of dealing with customer complaints and reclamations is specified by the process instruction customer complaints (,Kundenreklamationen", see /1.14/).
In case of software related system malfunctions the process instruction "Buchfuhrung und Behandlung von Softwarefehlern" (see /1.12/) has to be applied.
Exit criteria: Product end of life or dismantling of the channel on site.
All software tasks are listed in the project specific traceability matrix (PTM). This matrix must be created individually for each project and should list all software tasks to be done for this project.
The statuses of these tasks are documented in the PTM.
A minimum list of needed CIs (configuration items) is given in chapter 4 of this document.
Each software task and the resulting documents (CI) must be released by a review. The review sequence for each type of document is described in chapter 6 of this document. The sequence and relationship of the software tasks should be scheduled in the project specific time schedule plan.
Edition: 4 / 2013-02-18 Page 14 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 3.3. Roles and responsibilities The responsibilities and roles are defined in the project development plan (PDP) or the time schedule plan. Additionally to the PDP, all software tasks listed within the PTM may dedicate a responsible for each task. All software development tasks for the TK250 measuring system shall be executed only by people who possess the knowledge and abilities necessary for these tasks.
- 4. Documentation 4.1. Purpose The purpose of this section is to describe the minimal requirements for the project specific documentation. The minimum required documents are listed in the subchapters below. These documents and additional documents must be listed in the project specific traceability matrix (PTM).
The MGPI document templates must be used for the creation of the different documents.
4.2. Minimum documentation requirements All documents listed in the following subchapters must be presented in the correct format specified in: 0348585 A6, /1.4/. The review procedures for the different documents are described in chapter 6 of this document.
The language of these documents must be defined on a project specific basis, and has to be provided within the documents name, see /1.4/ "Anforderungen an Technische Dokumentation".
The language of each document is also defined in the PTM.
The internal distribution of documents including a notification of change or a notification of creation is performed by the QA department. Released documents must be provided to the QA department.
All quality assurance activities must be documented.
Expressions, abbreviations and conventions must be explicitly defined and explained in detail in the documentation.
4.2.1. Project development plan (PDP)
The project development plan shall be created in the start phase of the project. The PDP should detail the development activities foreseen in the current project. The software development process must be provided in detail in this plan. Information of all deliverables and outcome of the project in the different phases should be listed or a reference to this information must be provided.
4.2.2. Software requirement specification (SRS)
The SRS is used to list and define all software requirements. All requirements for the software must be described in detail and separated in such a way, that a requirements traceability matrix (RTM) can be derived from the SRS. The SRS should contain a description of all functional, non-Edition: 4 / 2013-02-18 Page 15 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) functional, internal and external requirements and external interfaces. The software requirements are derived from the system requirements.
The SRS should be conform with the standard IEEE 830, see /2.6/. The software requirement specification should be correct, consistent, unambiguous, verifiable, modifiable and complete.
4.2.3. Software design description (SDD)
The SDD should describe the software structure. The first architecture may be presented. All internal and external interfaces should be shown. The SDD should be consistent with the IEEE standard 1016, refer to /2.7/. Atop-down design is to prefer.
The software architecture, the software design and the elementary functionalities must be shown in the SDD. Data structures and communications between software parts should be shown inthe SDD.
With the information from the SDD a FMEA (Failure Mode and Effects Analysis) may be processed and the related FMEA document created. The results from the FMEA should be respected in the following development steps.
4.2.4. Verification and validation plan and result reports (SVVP)
A plan for the software verification and validation must be provided for each project. The V&V plan describes the verification and validation tasks and activities for each phase inthe software life cycle.
During the V&V activities all software changes should be verified/validated. As far as possible, all requirements should be tested. The test philosophy and techniques should be described. The results of the test-cases must be documented in a corresponding test result report. The V&V plan, the test procedures and the result reports shall be created in conjunction with the standard IEEE 1012, for more details refer to /2.8/.
4.2.5. User documentation The user documentation for the different TK 250 signal channel types is already present. An update of the user documentation is only necessary if a software update changes the functionality of the measuring channel or the described measuring principle of the measuring channel.
On an update of the users guides the VAW 0348 585 A6, refer to /1.4/, must be considered.
The related user documentation is provided with each signal channel type to the costumer.
A configuration specific Interface description and a configuration specific list of parameters must be created with each new set of EPROM parameters for a signal channel. These configuration specific documents must be listed in the project specific traceability matrix (PTM) and reviewed as described in chapter 6 of this document.
4.2.6. Software configuration management plan (SCMP)
The software configuration management plan shall be established to ensure the consistency, correct functionality and completeness of a software baseline. Ageneral SCMP is valid for use within all TK 250 software development processes. Additional requirements related to the SCMP may be covered in a separate project specific SCMP. This project specific SCMP must be created with attention to the IEEE norm 828, see /2.4/.
Edition: 4 / 2013-02-18 Page 16 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 4.2.7. Project specific traceability matrix (PTM)
The project specific traceability matrix should be created with each software project and should list all needed configuration items (documents, software files, hex-files, etc.), which must be provided with each software version (new software or new set of EPROM parameters). Additional information about the responsibilities for a Cl, the planned date of delivering and the current state of the CI may be provided by the PTM.
4.2.8. Requirement traceability matrix (RTM)
The requirements traceability matrix is derived from the SRS and the SDD and should provide a complete list of all requirements (functional, non functional) with unique requirement numbers to ensure a complete implementation and testing of all requirements.
The requirements traceability matrix is used in the project to list and check if the current project requirements are being met, implemented, verified and validated. New or changed requirements must be added or updated and tracked within the RTM. For this reason the RTM must be proved trough the different QA reviews.
- 5. Standards, practices, conventions and metrics The software development process is following the IEC 60880, ref /2.5/. The development process is subdivided into 8 phases. All phases of the software lifecycle model must be finished and the quality (conformity, consistency, correctness and completeness) must be assured by the different OA activities in each phase and at the end of the phase. The phases of the software life cycle are shown in the diagram below:
Page 17 of 29 Doc.-No.: 0348 664 A6OE 4 /I 2013-02-18 Edition: 4 Edition: 2013-02-18 Page 17 of 29 Doc.-No.: 0348 664 A60E
(1)
(D Phase 0 Specification of the Phase safety functions I-Customer Technical specification Customer 0 II Vi Validation specification VIII Specification-Verification z0 0
Software Design 'R.
0)
VII Design-Velfction IVI Module specification VI Of the Modull decription V V
Non-proprietary Version Software quality assurance plan (SQAP) 5.1. Documentation standards All documents (Cl's) must be listed in the PTM or the PDP. The release procedure described in chapter 6 of this document must be passed. All documents must be presented in a MGPI general form. This form is described in the VAW 0348585 A6, see /1.4/. The provided templates should be used. Additional project specific document forms may be defined and announced to the project team. For new document forms the following listed points must be considered (if applicable):
> Documentation standard
> Design standard
> Coding standard
> Commentary standard
> Testing standards and practices
> Selected software quality assurance product and process metrics All documents must be created with tools listed in chapter 9 of this document. The various documents must be stored in the project folder as described in the software configuration management plan (SCMP). All released documents must be printed/scanned/stored in the portable document format (PDF) additionally to the original document to provide an unchangeable and easily readable format.
The MGPI VAW 0348 250 B20, see /1.9/ must be respected for the controlling procedure of the document.
5.2. Requirements standards The requirements activities are performed in conformity to IEEE Std. 830, ref /2.6/.
5.3. Design standards The design standards are compliant to IEEE Std. 1016, ref /2.7/.
5.4. Coding standards The coding standard for the TK 250 system software, the commentary standard and the naming conventions are described in the coding rules, see /1.7/. The tools used during the implementation phase are listed in chapter 9 of this document. Other tools for the software production process must be evaluated before use.
The software development process for the TK 250 software must be executed on the isolated software-development-network. The assembler, the compiler and the linker for the software development process are archived in the software archive and must be checked before use.
At least each final released production software version must be archived in the MGPI software archive. The software archive procedure is explained in the corresponding VAW for software archiving, ref /1.5/.
5.5. Testing standards The testing standards are defined in the V&V plan (SWP), the test plan should follow the IEEE standard 1012, ref /2.8/.
Edition: 4 / 2013-02-18 Page 19 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 5.6. CM standards Configuration management procedures are described in the SCMP, ref to /1.6/.
5.7. Compliance monitoring The compliance of the outcome of the project is monitored during the review processes, described in chapter 6 of this document. Additional monitoring procedures may be executed with the QA reviews at the end of each project phase.
6.8. Meeting procedures Meeting procedures are not strictly defined. Meetings are carried out depending on the project course.
5.9. Metrics Failure rates of the different signal channel types and boards, including processor boards with software are continuous measured and evaluated. The MGPI internal VAW 0348 089 A06, ref
/1.10/, is valid for this procedure.
- 6. Software reviews The quality (compliance to standards, quality of content) of all documents produced is assured through reviews. The following listed reviews shall be executed as a minimum for a software project with a IEC 61226 category "A"safety classification. Reviews of documents which are not listed in the subchapters below should follow the same principle as shown in figure 3.
Every document has to be approved by the following participants:
> The author(s), to check for the correct content and the correct form;
> A team member, or project member to check and sign for the correct content;
> A member of the SQA team to check and sign for the correct form.
The team member/project member to check the correct content and SQA member to check the correct form should not be the same person. The standard conformity check (MGPI internal VAW, IEEE norm, etc.) of the document should be part of the SQA review.
Deviations or Improvements on the related documents, which are found during the review, must be corrected by the author. In this case a delta review is needed. The document shall not be signed if findings occurred.
Deviations or improvements found by the reviewer must be documented and reported to the author. A verification report shall be created. The report should contain information about the reviewer, the review activities and the review results. Solutions for deviations should be documented as well.
Reviews should be executed by persons who have the knowledge of the process and content and should not be directly involved in the creation process of the document.
Changes on already released documents must be verified and approved by authorized persons.
Edition: 4 / 2013-02-18 Page 20 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
Review protocol must be provided Fig. 3 MGPI internal approval of a document Doc.-No.: 0348 664 A6OE Edition'- 2013-02-18 Edition: 44 /I 2013-02-18 Page 21 Page of 29 21 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 6.1. Software requirement specification review The software requirements specification review is held to ensure that the requirements detailed in the SRS are consistent and to check if all relevant details have been included. Prior to the final agreement on the SRS with the client, the team should make sure that the SRS contains realistic and achievable requirements. The general review strategy is described in chapter 6 above.
The criteria to be examined in SRS will be:
> Has the purpose of the project been explained?
> Have the functional requirements been specified?
> Have the non-functional requirements been identified?
> Is the required program technically possible?
> Are the requirements complete?
> Are all constraints on the system described?
> Are the requirements objective and testable?
> Is the document understandable?
> Does the document form conform to the corresponding VAWs and norms?
> Have important interfaces to all system elements been described?
> Do major functions remain within scope, and have they been adequately described?
The SRS shall be verified against the RTM.
6.2. Software design review The Software Design Review is held to ensure the design structure is complete and clear, with respect to the SRS (using the RTM).
The document must describe the intended implementation structure for all aspects of the systems functionality. The interaction, structure and interfaces of each major routine must be shown.
The Software Detailed Design Review should verify whether the SDD describes routines capable of satisfying all requirements specified in the SRS.
The review will verify SDD by comparing it to the SRS and ensuring that every requirement can be traced to one or more parts of the SDD, which is a higher level description of the software.
The general review strategy is described in chapter 6 above.
During the review the following points shall be determined:
> Traceability: is there anything about this requirement in the SRS?
> Completeness: is this requirement completely satisfied by the design?
> Clarity: is this design sufficiently clear to ensure that the requirement is satisfied?
> Feasibility: can this design be implemented using the tools provided?
> Is the technical method of processing specified?
> Are all the major data structures specified?
> Can this functionality be unambiguously coded from this specification?
6.3. Module specification review Each changed module specification is reviewed to ensure the correct translation from the design to each software module. Unchanged module specifications must be checked for the correctness and completeness for the requirements from the current project.
29 Doc.-No.: 0348 664 A6OE 2013-02-18 Edition: 44 /I 2013-02-18 Edftion: Page 22 Page 22 of of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
Each demand from the software requirement specification and the design specification must be correct and complete translated to one or more software module(s). The interfaces between the modules must be approved and the data exchange and usage evaluated.
The general review strategy is described in chapter 6 above.
The criteria to be examined in module specification review will be:
> Has the purpose of the module been explained?
> Is the realization technically possible?
> Is the module complete?
> Is the document understandable?
> Are all functions and interfaces coherent?
> Is the portion of the functions useful?
> Do major functions remain within scope, and have they been adequately described?
> Does the document form conform to the corresponding VAWs and norms?
All module specifications should be traced to the requirement specification and the design specification.
6.4. Verification and validation plan review The review of the verification and validation plan is held to ensure the completeness, the adequacy and the correctness of the V&V plan. The test plan will be verified to contain testing criteria from all aspects of the system's functionality, as detailed in SRS, SDD. It should be checked that the test cases are applicable and sufficient to verify and validate the requirements.
The general review strategy is described in chapter 6 above.
6.5. Functional audit The interface specifications, which must be created for each separate signal channel and each separate EPROM parameter set, list and describe all external interfaces (analog outputs, analog inputs, binary in- and outputs, serial interfaces, etc.) of a signal channel and should therefore approved by the project team and optional by the customer. From this important document, the EPROM parameters settings of the different processor types (NZ12, NZ21 and NK21) are determined.
6.6. In-process audit After each development phase a QA review must be done to check the correctness and completeness of the corresponding phase.
This QA review is scheduled for the following phases:
> Software requirements specification
> Software design specification
> Module specification
> Implementation
> Testing
> Integration
> Validation Edition: 4 / 2013-02-18 Page 23 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
Development phases shall not be started unless the QA review from the preceding phase has successfully been finished.
The QA review is successfully done, if all belonging documents to the phase are complete, reviewed and released. The requirements traceability matrix (RTM) and the project traceability matrix (PTM) should be used in the QA reviews to check the completeness of the project phase.
6.7. Post implementation review The post implementation review (code review) must be finished after the implementation phase for each changed software module. The realization and the documentation of the post implementation review are following the "code review list", see /1.8/.
The check-list has to be processed, checked and documented accordingly. Any deviations or findings must be documented in the review document. Changes that occur in the code or the related documents after the review must be approved again by a delta review.
A list of the reviewed software files has to be established in the review report. This list has to provide the CRC32 checksums of all reviewed files.
6.8. Software configuration management review Before software release (release of a baseline) the completeness and correctness of the software configuration and all accompanying CIs must be checked. The inspection of completeness of all Cis is already part of the QA reviews. The purpose of the software configuration review is to check that the software output files (executables) are build correct and complete.
The archiving procedure for the software is described in a separate document, see /1.5/, and is done after the project is successfully finished.
The software configuration management review is divided in two parts:
6.8.1. Review of software modules The activities which are listed bellow must be performed by the software department:
> Check the correct physically storage of all software CIs at the isolated software server
> Verify the correctness of CRC32 of all software files for the release 6.8.2. Review of HEX output file The activities which are listed bellow should be part of the SVVP test activities:
> Check the reference checksum of the HEX files
> Check the correct software identification number of all HEX files for the different processor boards (NZ12, NZ21, NK21)
> Check software release form for the software delivery process , see /1.11/
> Test compilation to verify consistency of source code and hex-file The exact verification procedure of the HEX output file shall be part of the SWP.
EdRion: 4 / 2013-02-18 Page 24 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 6.9. External Reviews The content of the external reviews is defined project specific and depends mostly on the customer requirements or the safety classification of the product related to the external reviews. External software reviews are necessary on different reasons:
> IEC 60880 conformity
> KTA norm conformity (i.e. KTA 3503, ... )
> Customer request
> Internal request
> Safety classification of the product External reviews are defined project specific. The definition of Cl's which are reviewed external is done in the PTM or the PDP.
- 7. Test All test's shall be included in or referenced from the SVVP or related documents.
For the creation of the SVVP, the IEEE norm 1012, ref. /2.8/, must be respected.
- 8. Problem reporting and corrective action This section formulates solutions and provides a clear problem reporting method when problems occur.
There is a distinction between the problem handling during the development phases and the problem handling after the development phases has been finished.
8.1. Problem handling during software development phases Several problems can arise within the different Cl's:
> Inconsistency (in style or with other Cl's)
> Failure to comply to standards
> Incompleteness
> Implementation errors All issues, problems or anomalies identified in a Cl (documents, software or processes) must be reported and tracked. The strategy for anomaly tracking and reporting differs in the project phases:
Phase II:
Anomalies detected in this phase are collected in a table. This table must be evaluated and tracked and problems must be solved. A new version of the SRS and related documents are generated, if necessary.
Phase II:
Anomalies detected in this phase are collected in a table. This table must be evaluated and tracked and problems must be solved. A new version of the SDS and related documents are generated, if necessary.
Edition: 4 / 2013-02-18 Page 25 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
Phase IV:
Anomalies detected in this phase are collected in a table. This table must be evaluated and tracked and problems must be solved. A new version of the module specification is generated, if necessary.
Phase V:
Anomalies detected in this phase are reported in the code review document, ref /1.8/. Coding errors or anomalies must be solved after the review. A delta review of corrected software modules must be executed.
Phase VI:
Errors detected during module tests are reported in the test protocol. All errors must be evaluated.
For errors that require investigations, an anomaly report according to IEEE 829, ref /2.11/, must be created. Anomalies must be solved and corrective actions must be described in the AR. Tracking of the anomaly is done in the AR as well.
Phase VII:
Errors detected during integration tests are reported in the test protocol. All errors must be evaluated. For errors that require investigations, an anomaly report according to IEEE 829, ref
/2.11/, must be created. Anomalies must be solved and corrective actions must be described in the AR. Tracking of the anomaly is done in the AR as well.
Phase VIII:
Errors detected during validation phase are reported in the test protocol. All errors must be evaluated. For errors that require investigations, an anomaly report according to IEEE 829, ref
/2.11/, must be created. Anomalies must be solved and corrective actions must be described in the AR. Tracking of the anomaly is done in the AR as well.
8.2. Problem handling for delivered software The handling of anomalies for delivered products is addressed in /1.14/.
Anomalies which are detected after the validation phase of the system has been finished are collected within the MGPI "BuchfUhrung und Behandlung von Softwarefehlern", see /1.12/.
- 9. Tools, techniques and methodologies The tools and techniques listed in this section must be used. Other tools are not allowed to be used without evaluation of these new tools.
All team members which are involved in the process (documentation, software development) must be provided with the correct and relevant tools.
The documentation files, requirements specifications, design documents, test protocols and plans must be created with the tools listed in the "Documentation tools"- section below. All textual documents shall be created with Microsoft Word. Pictures, drawings and schematics shall be created with Microsoft Visio. The requirement traceability matrix (RTM) must be created with Microsoft Excel.
Edition: 4 / 2013-02-18 Page 26 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP) 1]
Additional tools, hardware or measuring instruments used in the different V&V activities shall be specified in the PDP. Translation tools (compiler, linker, etc) shall be listed with their exact version within the PTM, see also SCMP.
- 10. Media control The software development takes place on isolated software computers. All software files must be saved on the separate software development server in the current project folder (the software development computers and the software server are isolated from the company servers and the internet). Backup of the data on this server is done periodically by the software department.
The physically storage of the different software CIs are described in the SCMP, ref. to /1.6/.
Edition: 4 / 2013-02-18 Page 27 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SQAP)
A review of the correct and complete project folder takes place in the SCM (software configuration management) review before a software release as described in chapter 6.8. All software Cls (except binaries) are printed and stored in the project folder. The archive procedure of the software is described in /1.5/.
11.Supplier control The software for the TK 250 system is developed without external suppliers.
The tools used for the software development and the (( )) are used in different signal channel types and have been proven in several IEC 61226 category "A" projects since 1988. The output of the tools (hex-file) is verified and validated in each project.
For several KTA 3501 / 3503 applications the code produced with these tools has successfully type tested by TUV.
- 12. Records collection, maintenance and retention Records of meetings, technical problems, open points or questions should be stored in a project log-book.
All relevant documents created in the scope of a project will be approved and released. The released documents are saved and archived in an electronically and a printed format. The electronically archived documents are periodically stored to archive tapes for recovery purposes.
All documents are archived by the QA department, ref /1.9/.
The archiving procedure for the software is described in a separate document, ref /1.5/, and is done after the project is successfully finished.
13.Training General trainings for company standard tools (i.e. Microsoft Office), or company products and processes are organized by the company. All MGPI employees are trained periodically on these tools and the MGPI processes and products.
Each project team member must be trained and competent to finish the explicit project task.
New team members in the software department should be introduced in the MGPI software tool chain and processes.
If special skills are required for the processes and tools, trainings are organized individually.
- 14. Risk management Typical risks in a software project are the time planning, uncovered or misinterpreted requirements or changes on the final product during the project.
14.1. Schedule control The time planning must be checked with help of milestones in the project schedule plan at regular intervals. In case of any identified risks, the PM and the concerned project members must be involved in the process to classify the risk, evaluate the impacts to projects and define corrective actions.
Edition: 4 / 2013-02-18 Page 28 of 29 Doc.-No.: 0348 664 A60E
Non-proprietary Version Software quality assurance plan (SOAP) 14.2. Requirement control The requirements from the SRS should be discussed within the project team and with the customer in a early project phase. The interface specifications for each new set of EPROM-parameter should be created in the project and discussed within the project team and the customer.
Requirement changes during the project progression must be analyzed by the PM and the concerned project members to classify the risk, evaluate the impacts to projects and define corrective actions.
15.Glossary Refer to section 2.2 for the definition of the terms used in this SOAP.
16.SQAP change procedure The software department is responsible for updates on this SOAP. Changes on this software quality assurance plan (SOAP) must be reviewed and approved as described in chapter 6 of this document. If chapter 6 is updated, the new review strategy is also valid for this document.
Each change on a released version of this document must update the version number and must be described in the revision list on page 2 of this document.
2013-02-18 Page 29 of 29 Doc.-No.: 0348 664 A6OE Edition: 44 /I 2013-02-18 Page 29 of 29 Doc.-No.: 0348 664 A60E
,44 IT- 0 8 Non-proprietary Version MGPI1&B Miron Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany This Is a non-proprietary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( B]
Generic Software Verification and Validation Plan Digital nuclear measurement system TK 250 Copyright 2013. Mirion Technologies (MGPI H8B) GmbH AJInghts, including nghts patent and registered-design rights, where applicable, reserved. Transmittal, reproduction, or utilization of this dccurnent or disclosure of Its contents without expressed authonzatlon by the copyright holder are proibired. Violators shall be held liable for damages.
Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 MOnchen Fax: +49 (0)89 51513-169 Examin. of contents: Author: MGPI-SW, TBe Doc-No. 0348 666 A60E Formal release: M Page 1 of 20 Edition 2 12013-02-18 KItteiking EB1310058 Fie: Y:2\Tl 2\Software Verficaton and Vadodation Plan 03466.3 d0ckGA"9VN\Ed.'n E cd 2.docx
Non-proprietary Version Software verification and validation plan (SVVP)
List of Revisions Revision Date Scope of Revision Section page draft 2010-11-09 Draft edition all Changes after TUV review: Additional tools shall be listed Chapter within the PDP 4.6.1 Precision of description: internal and external reviews will be Chapter performed; separate review & verification reports will be 4.6.2.1 available 2010-11-24 Test coverage for module tests refined and justified Chapter 4.6.2.2 Changes after TUV review: Test coverage will be handled Chapter within the RTM and the different project specific test plans 5 Precision of description: task report can be a review report or Chapter a test report 6.1 2 2013-02-18 References in chapter 2.1 translated into English. Reference Chapter
/2.3/ corrected to 10 CFR 50 App. B 2.1 of 20 Doc.-No.: 0348 666 A6OE 2 // 2013-02-18 Edition: 2 2013-02-18 Page 22 of 20 Page Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
Table of Contents
- 1. Introduction ............................................................................................................................. 4 1.1 . P u rp o s e ............................................................................................................................... 4 1.2 . S co pe .................................................................................................................................. 4
- 2. Referenced Documents ................................................................................................... 5 2.1. References .......................................................................................................................... 5 2.1.1. MG PI internal documents ................................................................................................ 5 2.1.2. General quality procedures and instructions .............................................................. 5 3 . D e fin itio n s ............................................................................................................................... 6
- 4. V&V Overview ......................................................................................................................... 7 4.1. Organization ........................................................................................................................ 7 4.2. Master schedule .................................................................................................................. 8 4.3. Software integrity level scheme ...................................................................................... 8 4.4. Resources summary ..................................................................................................... 8 4.5. Responsibilities ................................................................................................................... 8 4.6. Tools, techniques and methods ...................................................................................... 9 4 .6.1 . T o o ls ............................................................................................................................... 9 4.6.2. Techniques and Methods .......................................................................................... 9
- 5. V&V Processes ..................................................................................................................... 10
5.1. Process
Management .................................................................................................. 11
5.1.1. Activity
Management of V&V .................................................................................... 11
5.2. Process
Development ................................................................................................. 11
5.2.1. Activity
Concept V&V ................................................................................................ 11
5.2.2. Activity
Software Requirements V&V ...................................................................... 11
5.2.3. Activity
Design V&V (Software Detailed Design) ...................................................... 12
5.2.4. Activity
Module specification V&V ............................................................................ 13
5.2.5. Activity
Im plementation V&V ..................................................................................... 14
5.2.6. Activity
Module test V&V ........................................................................................... 14
5.2.7. Activity
Integration test V&V ..................................................................................... 15
5.2.8. Activity
Validation test V&V ....................................................................................... 15
5.2.9. Activity
EPROM parameter V&V .............................................................................. 16 5.2.10. Activity: Installation and checkout V&V ..................................................................... 17
5.3. Process
Operation ............................................................................................................ 17
5.3.1. Activity
Operation V&V ............................................................................................. 17
5.4. Process
Maintenance ................................................................................................... 17
5.4.1. Activity
Maintenance V&V ......................................................................................... 17
- 6. V&V Reporting Requirements .......................................................................................... 18 6.1. Task reports ...................................................................................................................... 18 6.2. Phase summary reports .............................................................................................. 18 6.3. Anomaly reports ................................................................................................................ 18 6.4. V&V final report ................................................................................................................. 19
- 7. Administrative Requirements ............................................................................................. 19 7.1. Anomaly resolution and reporting .................................................................................. 19 7.2. Task iteration policy ........................................................................................................... 19 7.3. Deviation policy ................................................................................................................. 19 7.4. Control procedures ............................................................................................................ 19 7.5. Standards, practices, and conventions ......................................................................... 20
- 8. V&V Test Documentation Requirements ......................................................................... 20 Edition: 2 / 2013-02-18 Page 3 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
- 1. Introduction 1.1. Purpose The purpose of this software verification and validation plan (SVVP) is to describe the test procedures and test strategies used during the software development process for the TK250 system, to assure the quality of the product to be delivered and the specified requirements are meet and complete.
The described verification and validation procedures and strategies are applicable to all processor boards used in a TK 250 system and the complete measuring system including the processor boards and other 10-boards.
The SVVP describes the organizational elements and responsibilities for the verification and validation activities. The required documentation for all V&V tasks is defined and described in this plan.
The format of this SVVP is compliant to IEEE 1012 standard, ref. to /2.5/ and complies with the demands from the IEC 60880, §8, ref. to /2.4/.
1.2. Scope The product portfolio of Mirion Technologies (MGPI H&B) GmbH is subdivided into radiation monitoring and neutron flux monitoring systems. They consist of detectors and a modular TK250 electronic board system. In these measuring systems microcontroller boards are used for signal processing purposes (for example: NZ 21, NZ 12 and NK 21). These boards are equipped with application specific software (firmware).
This V&V plan describes the software test strategy, the test methods and the necessary test documentation for the software of those TK 250 systems (channels), which are designed for the use in IEC 61226 category A or 1 E applications. It is thus applicable for the software of the following neutron flux monitoring channels and variations of these channels: DAK 250, DGK 250, DWK 250, DMK 250, DSK 250 and DLK 250.
This document lists and defines the required verification and validation activities, describes the management activities and outlines the anomaly and deviation policies.
The test organization is shown in detail. In chapter 4.2 a time schedule handling for all V&V activities is proposed. The responsibilities for the test planning, the test execution and test management are defined. The different V&V processes and activities are listed and described.
This plan specifies the required V&V activities for the phases II to VIII of the software development phases:
- 1. System requirement specification II. Software requirement specification Ill. Software design specification IV. Module specification V. Implementation VI. Module test VII. Integration test VIII. Validation test Edition: 2 / 2013-02-18 Page 4 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
- 2. Referenced Documents 2.1. References 2.1.1. MGPI internal documents
/1.1/ Quality management manual (QMM) Doc.-No. 0348 250E ed7
/1.2/ Process description Doc.-No. 0348 250 B20E ed4
/1.3/ Requirements and procedures for Class-1 E-Equipment Doc.-No. 0348 591 A50E edl
/1.4/ Requirements for technical documentation Doc.-No. 0348 585 A6E ed2
/1.5/ Guidelines and rules for the software archive Doc.-No. 0348 074 A61E ed2
/1.6/ Software configuration management plan (SCMP) Doc.-No. 0348 665 A60E ed2
/1.7/ Software coding rules and standards for TK 250 Doc.-No. 0348 662 A60E ed2
/1.8/ Code review check list for TK 250 software Doc.-No. 0348 662 L60E edl
/1.9/ Software quality assurance plan (SQAP) Doc.-No. 0348 664 A60E ed4
/1.10/ Software handover protocol Doc.-No. 0348 121E
/1.11/ EPROM for TK 250 Doc.-No. 5-1105E ed3 2.1.2. General quality procedures and instructions
/2.1/ Quality managements systems - requirements DIN EN ISO 9001-2008
/2.2/ Quality assurance requirements KTA 1401 - 1996
/2.3/ NRC Regulations (Nuclear Regulations) 10 CFR 50 App. B 12.41 IEC Standard for software in nuclear plants DIN EN 60880:2009
/2.5/ IEEE Standard for Software Verification and Validation IEEE Std. 1 0 1 2 TM -2004
/2.6/ IEEE Standard for Software Test Documentation IEEE Std. 8 2 9 TM - 2008 Edition: 2 / 2013-02-18 Page 5 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
- 3. Definitions AR Anomaly report Cl Configuration item MGPI Mirion Technologies (MGPI H&B) GmbH (manufacturer/ supplier)
PDP Project development plan PTM Project specific traceability matrix QA Quality assurance QAP Quality assurance plan QMM Quality management manual QMS Quality management system RTM Requirement traceability matrix SCMP Software configuration management plan SDD Software detailed design SRS Software requirement specification SQA Software quality assurance SWP Software verification and validation plan TOV Technischer Uberwachungsverein VAW MGPI process instruction (Verfahrens-Anweisung)
Edition: 2 / 2013-02-18 Page 6 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
- 4. V&V Overview 4.1. Organization The complete and current organization of the Mirion Technologies (MGPI H&B) GmbH is shown in the company organization chart in the QMM, see /1.1/ §2.4.
For software development projects in the scope of this V&V plan, the V&V activities shall be carried out by the following V&V teams:
" Independent V&V team according to IEC60880 [i.e. TOV or similar organization]
- Independent test field departmentat Mirion Technologies The independent V&V team is responsible for the V&V activities of the development phases II to VIII, while the independenttest field departmentin the frame of the software development process is responsible for dedicated validation tests.
With this organization the test management and the test teams are independent from the project management and the development management.
At Mirion an engineer (V&V engineer/manager) is responsible for the communication between Mirion and the independent V& V team and for supporting activities under the supervision of the independent V&V team.
The general organization of the V&V teams, and the relationship between the project members is shown in the figure 1 below:
((
11 Picture I General V&V Organization Edition: 2 1 2013-02-18 Page 7 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
Throughout the development phases II to V the software development department produces the software and the related documents, which have to be verified and validated in the phases II to VIII. It publishes the status of these items and grants read only access to them. Thus any modifications of these items are carried out by the software development department.
The results of the software development department are distributed to the project manager, QA manager, test field department and via the V&V manager to the independent test team. The customer must be provided with the user documentation, test result documentation and all quality assurance documents.
The development department must be provided with test results, anomaly reports and activity reports of the different V&V activities. The QA manager is involved in or informed about all V&V activities to verify the completeness and consistency to the internal and external quality demands.
The communication between the development team and the test team(s) must be formal and in written form at a level of detail which may be audited.
4.2. Master schedule The time schedule for the V&V tasks (for each phase of the project) is dependent on the project time schedule plan. In each development phase the related V&V tasks are carried out only after that development phase of the project is deemed complete by the PM and the development team.
The QA review at the end of each phase should be included in the time schedule plan as a milestone. The V&V activities must be considered in the project time schedule plan.
4.3. Software integrity level scheme This verification and validation plan applies to the software of those TK 250 systems (channels),
which are designed for the use in IEC 61226 category A or 1E applications.
For this reason the software integrity level scheme is identified to fulfill the demands from the IEC 60880, see /2.4/.
4.4. Resources summary The V&V effort is scheduled within the project time schedule plan. Department internal technical resources (facilities, tools or special procedural requirements), which are already available at the start of the project and are used only within the department, are planned individually by the different departments. All other technical resources are planned by the project manager.
4.5. Responsibilities The responsibilities are defined in the project development plan (PDP) or the time schedule plan.
All V&V tasks for the TK250 measuring system shall be executed only by people who possess the knowledge and abilities necessary for these tasks.
The external and independent V&V team is a project member. It is responsible for the verification and validation processes in the different development phases. The internal independent test field department (PrOffeld) is mainly responsible for system validation and functional testing.
The correct and explicit definition of the responsibilities of both V&V teams is defined in the PDP.
20 Doc.-No.: 0348 666 A6OE Edition: 2 2 // 2013-02-18 2013-02-18 Page 8 Page 8 ofof 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP) 4.6. Tools, techniques and methods 4.6.1. Tools All tools used for the validation or verification processes must be documented in the test protocols.
The list of used tools within the test protocol must ensure the possibility to repeat each test case in the protocol complete and correct.
Measurement instruments (i.e. multi meters, current sources, oscilloscopes, etc.) which are used in verification and validation tests, shall be calibrated. The expiration date of the calibration shall be noted in the test protocol.
A list of those tools, which are allowed to be used during the different development phases and the V&V activities, is given in the SQAP, ref to /1.9/. If additional tools are needed for the V&V activities in the current project, these tools shall be specified in the project specific development plan (PDP).
4.6.2. Techniques and Methods 4.6.2.1. Verification of documents All Documents created in the project scope must be verified by a internal review. Successful reviewed documents are signed by the reviewer. If the content is reviewed and verified, the document is approved by the QA manager and signed for the formal release. The complete verification strategy for documents is described in the SQAP, ref to /1.9/. A review protocol must be available.
The review and approval the document must be performed by persons who have the necessary knowledge of the concern of the document and who are involved in the project.
An additional review shall be performed by an external organization (e.g. TOV).
For the verified document there will be a review protocol from MGPI and a complete and independent verification report from TOV. The verification report from TUV will be more detailed.
The details should be provided in the project specific development plan (PDP) and the PTM which contains dedicated review columns.
In some development phases there will be several documents of a similar type (for instance module specifications). In these cases the TOV will provide a single verification report which deals with a group of verified documents.
4.6.2.2. Verification of source code All changed software modules are verified by a code review and tested by a module test. The code review must verify the correctness, the consistency and the compliance to the implementation standards and the design standards. The review shall verify that the code fulfills the relevant requirements. The code review must be documented and found issues have to be resolved. A code review form shall be used for the code review execution and documentation, see ref to /1.8/.
The code shall be reviewed by a "walk-through" or a "4-eyes inspection" (or a combination of both methods). The Code-Review must be carried out by a software developer who owns the necessary knowledge about the TK 250 system and the software.
The module test must cover all changed functions and code sections. All new or changed interfaces must be verified and evaluated.
The software module tests should be executed preferable on the real target or a simulator.
A detailed test plan must be created and the test results must be documented in a form that the tests are repeatable and auditable. If issues or errors are detected an anomaly report shall be created.
Edition: 2 / 2013-02-18 Page 9 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
The test coverage will be justified for all modified modules and even for the non modified ones.
References to existing documented test cases are accepted for non modified modules after being justified relevant in the new design.
4.6.2.3. Verification during integration Each integration step should be evaluated by a dedicated test case. For every dependence between two or more components (software modules or hardware interfaces) of a system a test scenario is defined which is able to demonstrate that each data interchange between two or more components of the system is correct and complete. All software design specifications shall be verified.
The integration tests shall be executed on the real target or a simulator. Any variation from the expected results shall be investigated. If issues are detected an anomaly report shall be created.
The test documentation and the test results shall be provided in a form which is auditable by persons not directly engaged in the verification processes, but nevertheless who are familiar with the details of the TK250 system. The test documentation must ensure repeatability of each test case.
4.6.2.4. Validation tests Each requirement should be validated by a test case. All relevant outputs from the system under test shall be monitored and evaluated. The validation tests shall be executed on the real target (i.e.
TK 250 measuring channel). All specified software requirements shall be validated.
Any variation from the expected results shall be investigated. If issues are detected an anomaly report shall be created.
The test documentation and the test results shall be provided in a form which is auditable by persons not directly engaged in the validation processes. All test cases must be repeatable and auditable.
- 6. V&V Processes Software V&V should begin when the project starts. The planning documents, the concept documents and the quality documents (SQAP, SCMP, etc) must be evaluated to be usable for the current project and deviations must be remedied.
All V&V activities must be planned and managed. Each development phase (V-cycle) must be finished with the V&V activities described in this plan. The results of the V&V activities in the different development phases must be documented in the appropriate documentation form. The test coverage must be critically considered and test cases are designed to test the TK 250 signal channels and the software (firmware) as depth as possible and reasonable. A strategic and systematic test plan must be designed for each type of test (test phases VI to VIII). The requirements traceability matrix should be used to trace the test coverage. Each test plan should specify the test coverage criteria as well as the applied test techniques and test methods.
Each V&V task and the results must be documented in a written and complete format. V&V tasks, which are not listed in the following sub-chapters, must be documented and a report must be created in the same manner as described in this plan. All V&V tasks to be executed in the scope of the project must be listed within the project specific traceability matrix (PTM).
2013-02-18 Page 10 of 20 Doc.-No.: 0348 666 A6OE Edition: 22 /I 2013-02-18 Edition: Page 10 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
6.1. Process
Management
5.1.1. Activity
Management of V&V The process of software V&V needs to be managed and performed comprehensively over the entire software development process (V-cycle). The management of the V&V activities must be independent from the development management.
V&V management tasks, spanning all of the software development activities in all development phases, are to:
- Plan and maintain the software V&V process over all development phases
- Coordinate and interpret performance and quality of the software V&V effort
- Report discrepancies promptly to the project manager or development manager or to the costumer
- Identify early problem trends and focus software V&V tasks on them
- Monitor all V&V efforts
- Assess the full impact of proposed software changes
5.2. Process
Development
5.2.1. Activity
Concept V&V The system requirements specification from the customer is analyzed and a specific implementation solution is selected and defined to solve the customer requirements. In the concept phase a system is selected (existing signal channel type or new implementations) to fulfill all costumer requirements. The objective of concept V&V is to verify the allocation of system requirements, validate the selected solution, and ensure that no false assumptions have been incorporated in the solution.
The concept phase is an optional phase and is supposed in projects with complete new software implementations. The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output Concept documentation
- Evaluated and released Concept document with review evaluation report(s)
Requirements allocation 0 Hardware/software/user requirements allocation analysis Traceability analyses
- requirement traceability matrix Prototyping 0 prototype with documentation QA review execution a end of phase report(s) 0 traced and verified PTM
5.2.2. Activity
Software Requirements V&V The software requirements V&V activity checks that the transformation of system requirements to software requirements is appropriate, complete, non-ambiguous and correct. The segmentation of the software requirements and the description should support, as far as possible, complete testability of all requirements. An SRS shall be available for all software systems to be developed and delivered. The software requirement specification verification should be performed by internal reviews and additionally verified by the independent test team.
Edition: 2 / 2013-02-18 Page 11 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
The software requirement traceability matrix derived from the software requirements specification must be verified and checked for completeness.
An interface specification for each set of EPROM parameters must be created at the end of this phase. The requirement V&V activities must verify the correctness and completeness of all interface specifications. The interface specifications may be additionally approved by the customer.
Concurrently with the software requirements V&V, software system test planning should be initiated. Software V&V examines all the proposed testing for the system to ensure that comprehensive testing and appropriate resources are planned. As far as possible each requirement shall be verified by a dedicated test case. The test coverage criteria should be considered.
The following test plan should be initiated during this phase:
- System V&V Test Plan The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output SRS review
- Evaluated and released SRS with review report(s)
Traceability analyses a complete requirement traceability matrix Interface specification
- complete interface specification for each planned set of review EPROM parameters and review report(s)
QA review execution a end of phase report(s) 9 traced and verified PTM
6.2.3. Activity
Design V&V (Software Detailed Design)
The software design V&V activity occurs after the software requirements V&V process has been successfully finished and the software design, or an increment of the software design, has been completed.
The software design V&V tasks of traceability, evaluation, and interface analysis provide assurance that software requirements are not misinterpreted, incompletely designed, or incorrectly designed.
By verifying that the software design meets its software requirements, the software design V&V activity also supports validation that the software design meets system requirements (if the software requirements specification is complete and correct).
When the software system is designed, changed software parts and software modules must be identified, described and justified. New software modules must be planned. The design decisions must be reviewed und verified. The design must involve all needed processor boards for the signal channel. All requirements shall be portioned to the different used processor boards (NZ12, NZ21, and NK21) in the signal channel. The software design specification verification should be performed by internal reviews and additional verified by the independent test team.
The technical feasibility of the design, the testability, the readability and the changeability of the design documents must be evaluated and documented. The safety critical functions and the realization of these functions must be evaluated. The design of the software must match the general design rules.
The updated traceability matrix with the additional requirements from the design phase must be reviewed; the completeness and correctness must be verified.
Edition: 2 / 2013-02-18 Page 12 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
The design V&V activities and the results must be documented in the appropriate review document.
Optional at the end of this phase a design FMEA may be executed to identify possible software problems based on the software design.
The following listed test plans should be prepared during this phase:
- Integration V&V test plan The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output SDD review
- Evaluated and released SDD with review report(s)
Traceability analyses
- complete and updated requirement traceability matrix with additional requirements from the design phase FM EA execution e FMEA task documentation
( FMEA result documents with review report(s) and (optional) recommendations QA review execution a end of phase report(s) a traced and verified PTM
5.2.4. Activity
Module specification V&V The module specification V&V tasks start after all V&V tasks of the previous phases are successfully done and the design document is complete and correct.
The software design is segmented into different software modules. The software module descriptions are updated according to the verified and proved design documents.
The completeness, correctness, consistency and testability of each new or changed software modules must be evaluated and documented. The module specification verification should be performed by internal reviews and additional verified by the independent test team from the TUV.
The already existing module specifications of all processor boards (NZ12, NZ21, and NK21) are checked and updated if needed. New or changed software module descriptions must be verified and a verification report for each changed module description must be created. All module specifications must be traced to the software requirements specification and the detailed software design specification to meet these specifications and ensure completeness.
The following listed test plans should be prepared during this phase:
- Module V&V test plan for each new or changed software module Edition: 2 / 2013-02-18 Page 13 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output 0 New or Updated, evaluated and released module Review of module specification(s),
specifications a review report(s) of all module specifications for all processor boards Traceability Analyses
- complete and traced requirement traceability matrix QA review execution
- end of phase report(s)
5.2.5. Activity
Implementation V&V The code verification activity verifies the correct implementation of software design and module descriptions into source code. This activity requires tedious checking of details within the code and in the module specifications by a code review. It must be validated that all planed functions implemented and no unwanted functions are implemented. The results of the code review must be documented in the code review document, see /1.8/. Code corrections resulting from the review must be reviewed again by a delta-review.
The code review is a formal and theoretical procedure to check the software code module in a static way. The code review is performed by the author of the code module and a second software developer who has the qualification and knowledge of the software of the TK 250 measuring system.
The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output 0 New or updated, verified and released source code files with Source code review review report(s) of all modules for all processor boards a complete list of all software modifications in all processor boards Traceability analyses
- complete and traced requirement traceability matrix QA review execution 0 end of phase report(s) 0 traced and verified PTM
5.2.6. Activity
Module test V&V Static source code verifications are already done in the implementation phase (code review).
Additional module test cases on the level of the software objects are executed in this phase. Each changed software module must be tested / retested after any changes made in this module. The software modules must be analyzed in detail to determine the program flow, verify the requirements, check for unreachable code sections and correct implementation. Detailed test procedures must be described, executed and the results have to be documented.
A detailed test plan for each changed software module must be created and the test results must be documented. Each module test plan must contain a test coverage matrix.
The software test cases are drafted by the development department and authorized and executed by or in presence of the independent test team. The module test activities are carried out by an engineer from MGPI under supervision from TUV.
Additional analysis on the software modules are carried out by the independent V&V team and are defined project specific in the PTM.
Edition: 2 / 2013-02-18 Page 14 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output Module test plans 0 New or updated module test plans for each changed or new generation software module with review protocol Module test execution
- documentation of module test results a anomaly report(s)
Traceability analyses
- complete and traced requirement traceability matrix QA review execution 0 end of phase report(s) a traced and verified PTM
5.2.7. Activity
Integration test V&V The verified software modules are integrated into the complete software and hardware environment. The interaction between hardware, the different software modules and the processor boards (NZ12, NZ21 and NK21) must be tested and verified.
Changed interfaces between different software modules must be evaluated for impacts from one software module to the other software modules and if applicable to the hardware.
The integration tests must be performed according to the detailed integration test plan. At least the normal behavior of the software and the worst cases of the input domains to the software or to the system must be tested. The test results must be documented in the integration test protocol. A detailed test plan for the integration phase must be created. The test plan must contain a test coverage matrix. The test cases are drafted by Mirion. They are reviewed and approved by the independent test team (TOV) before the tests are carried out.
The integration test activities are performed by TUV or an engineer from Mirion under supervision from TOV.
Additional analysis from the TUV on the software executable (HEX-file or OBJ-files) may be carried out and are defined project specific in the PTM.
The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output Integration V&V test plantegenration t Detailed integration test plan with review protocol plan generation Integration test 0 documentation of results of each integration test from each execution integration phase a anomaly report(s)
Traceability analyses a complete and traced requirement traceability matrix QA review execution a end of phase report(s) 0 traced and verified PTM U.2.8. Activity: Validation test V&V The purpose of validation is to demonstrate that the integrated system of hardware and software correctly executes the functions as defined in the system requirements specification and the software requirement specification.
Software verification, in the context of software V&V, involves the conduct of tests to execute the completely integrated system. Validation of the complete system may involve many tests with all system components or a complete system emulation test environment.
Page 15 of 20 Doc.-No.: 0348 666 A60E Edition: 22 // 2013-02-18 Edition: 2013-02-18 Page 15 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
Validation requires testing of the complete integrated TK 250 signal channel and the firmware, to determine that the system performs all specified functions completely, correctly, consistently and accurately. During the validation process, all interfaces with the other systems and with users must be evaluated.
Validation must assess whether the key performance parameters, critical functions and other system requirements have been achieved, and must demonstrate that the system fulfills the system requirements specification. For this reason validation and the validation test planning should be based on the system requirements specification.
The tests shall be performed following the detailed validation test plan and the results must be documented in the validation test result document. This plan is drafted by Mirion. It is reviewed and approved by the independent V&V team before the tests take place.
The validation tests are performed by the internal test field department (Pr~ffeld) in conjunction with the independent test team (TUV).
The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output Validation V&V test
- Detailed validation test plan with review protocol plan generation Validation test execution a documentation of results of each validation test 0 anomaly report(s)
Traceability analyses 0 complete and traced requirement traceability matrix QA review execution a end of phase report(s) a traced and verified PTM
5.2.9. Activity
EPROM parameter V&V A set of software system and application specific settings of the EPROM based parameters is created for each type of signal channel to be delivered by MGPI. These parameters are mainly used to define the different I parameters and the UI parameters of the signal channel.
The EPROM parameter tests must be executed for each set of EPROM parameters for each type of signal channel. The test cases must be designed to demonstrate the correct functionality of each interface of the TK 250 signal channel and the correct content of the HEX-file (correct software section and correct EPROM parameter section). The interfaces must match the requirements specifications and the interface specification of each signal channel type.
In case of a user interface text translation, the correct translation must be evaluated. The key properties of a software package (i.e. name of the software, name of the processor board, software id numbers, CRC checksum for the EPROM content, ... ) are documented in a software handover protocol (see /1.10/).
The EPROM parameter verification and validation activities are carried out by the internal test field department ("Priffeld'). An additional analysis is then performed by the TUV, and will be defined on a project specific basis in the PTM. All results of the different tests must be documented.
2013-02-18 Page 16 of 20 Doc.-No.: 0348 666 A6OE Edition: 22 // 2013-02-18 Edition: Page 16 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output EPROM parameter V&V , Detailed functional test plan for EPROM parameter tests with test plan generation review protocol EPROM parameter test 0 documentation of results of each EPROM parameter test execution 0 anomaly report(s)
QA review execution 0 end of phase report(s)
- traced and verified PTM and RTM 5.2.10. Activity: Installation and checkout V&V The installation and checkout V&V activities verify the completeness and correctness of all products (Cls) to be delivered. The software executable (hex-file), the documentation and all other out-comes of the project for the specific signal channel are checked and listed.
The correctness and completeness of this package must be approved and the package released.
The complete software and the documentation must be stored correctly as described in the archiving procedures, see /1.5/ and /1.1/.
The CM reviews and evaluations, as described in the SCMP (see /1.6/) must be finished at the end of this phase.
The installation of the software consists of copying the content of the Intel HEX-file into an appropriate EPROM. The selection of the EPROM type, microcontroller board type and EPROM label layout are based upon information from the document "EPROM for TK 250" /1.11/ and its associated documents. The correct EPROM label must be verified. This board and the new EPROM are then tested in a TK 250 channel. This installation process and its verification are executed by staff from the test field department.
The appropriate V&V tasks for this phase are as follows:
V&V task Required V&V output Installation and a Task report(s) configuration audit a Complete and released software for a TK 250 signal channel 0 Anomaly report(s)
V&V final report a Summarize in the V&V final report the V&V activities, tasks, and generation results, including status and disposition of anomalies.
QA review execution a end of phase report(s) a traced and verified PTM and RTM
5.3. Process
Operation
5.3.1. Activity
Operation V&V Operation of the TK 250 channels and its software (firmware) is governed by the QMM, see /1.1/.
5.4. Process
Maintenance
5.4.1. Activity
Maintenance V&V Maintenance of the TK 250 channels and its software is governed by the QMM, see /1.1/.
Edition: 2 / 2013-02-18 Page 17 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP)
- 6. V&V Reporting Requirements This chapter describes how the results of the V&V activities will be documented, detailing the content and format of all V&V reports. The different V&V reports produced in the different phases will together comprise the SWR document.
6.1. Task reports Each V&V task must be documented and the results reported. A task report can be a review report or a test protocol. The review document shall contain the task identification and a short task explanation. All results of the V&V task and the status information of the task must be documented in the report.
Corrective actions and tracking information of these actions shall be available in the task report.
Where a task does not succeed in the first task report, subsequent task reports will be made for the repeated V&V task until it succeeds.
Existing task report forms shall be used (code review document, etc.). The IEEE Std 829 defines form and content of different task reports. This standard must be respected for the creation and the usage of a task report, see /2.6/.
6.2. Phase summary reports Each V&V specific task will be accompanied by a phase summary report at the end of each phase (QA review). Summary reports will contain at least the following information:
- 1. Phase
- 2. Description of V&V tasks performed
- 3. Summary of task results
- 4. Summary of detected anomalies and resolution
- 5. Assessment of overall software quality
- 6. Recommendations for next phase(s)
- 7. Open points or issues
- 8. Status (complete or incomplete)
- 9. Date
- 10. Participants 6.3. Anomaly reports Anomalies may be detected in each development phase by different V&V activities. An anomaly report will be produced for each anomaly detected by a V&V effort, especially in the testing phases. Each anomaly report will contain at least the following information:
- 1. Description and location
- 2. Tracking number
- 3. Date and time filed
- 4. Impact
- 5. Cause
- 6. Criticality
- 7. Recommendations
- 8. Test responsible
- 9. Anomaly responsible Edition: 2 / 2013-02-18 Page 18 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SWVP)
The anomaly report form template (AR) shall be used.
6.4. V&V final report The results of the different V&V tasks in the development phases must be reported. All V&V reports constitute the final report (SWR). This SVVR is created in the close-out phase of the project. This report will contain the following information:
- 1. Summary of all software life-cycle V&V tasks
- 2. Summary of task results
- 3. Summary of anomalies and resolutions
- 4. Assessment of overall software quality
- 5. Recommendations
- 7. Administrative Requirements 7.1. Anomaly resolution and reporting Anomaly resolution and reporting is described in the SQAP, §8, see /1.9/.
The IEEE Std 829, ref to /2.6/, defines form and content of an anomaly report. This standard must be respected. The minimum content of an anomaly report is listed in chapter 6.3 of this document.
7.2. Task iteration policy If the software requirement specification, the detailed design specification, a software module or its specification, a test case or procedure itself is changed after finished tests or reviews, the test case or the review for the affected document(s) or software module must be repeated. In this case new test or review reports must be generated.
7.3. Deviation policy Deviations from the V&V procedures must be communicated to the project manager and the development department(s). Each deviation must be justified and the impact to the quality of the software has to be evaluated.
Deviations should be generally avoided. Each deviation report must be signed by the test manager, the project manager and the development responsible.
7.4. Control procedures All V&V documents must be named and stored as described in the SQAP and the SCMP. The naming conventions for documentations, as described in the SCMP, ref to /1.6/, must be applied.
The quality procedures as described in the SQAP (see /1.9/) are also valid for all V&V documents.
All V&V reports must be provided to the QA department. The QA department is responsible for the archiving and control procedures of the V&V documents.
Edition: 2 / 2013-02-18 Page 19 of 20 Doc.-No.: 0348 666 A60E
Non-proprietary Version Software verification and validation plan (SVVP) 7.5. Standards, practices, and conventions The software development process is following the IEC 60880, ref /2.4/. The development process is subdivided into 8 phases (see SQAP, /1.9/) which are listed in chapter 1.2 of this document. All phases of the software lifecycle model must be finished and the quality (conformity, consistency, correctness and completeness) must be assured by the different QA activities in each phase and at the end of the phase as described in chapter 5 of this document.
- 8. V&V Test Documentation Requirements Existing templates of the V&V documents mentioned in this V&V plan must be used. If no template is available a template shall be created, released and used. The format and the content of these documents are defined in the IEEE Std 829, ref to /2.6/. This standard shall be respected for the creation and usage for these documents.
All test and review documents from the different V&V tasks must be presented in the correct format specified in: 0348585 A6, see /1.4/.
Edition: 2 / 2013-02-18 Page 20 of 20 Doc.-No.: 0348 666 A60E
M / T- 108(c)
Non-proprietary Version MGPII&B Midon Technologies (MGPI H&B) GmbH Nuclear Measurement - Munich, Germany This is a non-proprietary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are Indicated by two opening and two closing brackets as shown here: (( 1]
Generic Software Configuration Management Plan for TK 250 systems Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 M~nchen Fax: +49 (0)89 51513-169 Exam in. of contents: I t- Author: MGPI-SW, TBe 7"* Doc-No. 0348665 A60E Formal release: 4 Page 1 of 21 Edition 2 12013-02-18 Mitteilung E-1310058 _QA\SCMPEdition2\Software Configuration Management Plan (13486*55A6E ed 2.docx File: Y:\TIQS2CU\S
Non-proprietary Version Software configuration management plan (SCMP)
List of Revisions Revision Date Scope of Revision Section page Draft 2010-10-12 Draft edition all Draft 2010-11-09 Changes in chapter 4.1.2 after TE review Chapter 4.1.2 Reference to SQAP updated to current edition 3 Chapter 2.1.1 1 2010-11-24 Changes after TUV review: Added *.INF file to list of software Chapter files, spelling correction in this chapter 4.2.1.4 Changes after TJV review: Added chapter 4.2.1.10 Chapter
__________ ____________________________________ 4.2.1.10 2 2013-02-18 References in chapter 2.1 translated into English. Reference Chapter
/2.3/ corrected to 10 CFR 50 App. B 2.1 Doc.-No.: 0348665 A6OE Edition: 2013-02-18 22 /I 2013-02-18 Page 2 Page of 21 2 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
Table of contents 1 Introduction ............................................................................................................................. 4 1.1. Purpose ............................................................................................................................... 4 1.2. Scope .................................................................................................................................. 4
- 2. References, Abbreviations and Acronym s ......................................................................... 5 2.1. References .......................................................................................................................... 5 2.1.1. MG PI internal docum ents ........................................................................... 5 2.1.2. General quality procedures and instructions .............................................................. 5 2.2. Abbreviations and Acronym s ........................................................................................... 6
- 3. Overview ................................................................................................................................. 7 3.1. CM overview ....................................................................................................................... 7 3.2. Software organization ................................................................................................. 8
- 4. The software configuration m anagem ent plan ..................................................................... 9 4.1. SCM management ..................................................................................................... 9 4.1.1. O rganization .................................................................................................................... 9 4.1.2. SCM responsibilities ................................................................................................. 10 4.1.3. Applicable policies, directives and procedures .......................................................... 12 4.2. SCM activities ................................................................................................................... 12 4.2.1. Configuration identification ........................................................................................ 12 4.2.2. Configuration control ................................................................................................. 19 4.2.3. Configuration status accounting ................................................................................ 19 4.2.4. Configuration evaluation and reviews ....................................................................... 20 4.2.5. Tracking ......................................................................................................................... 20 4.2.6. Interface control ............................................................................................................. 20 4.2.7. Subcontractor / Vendor control .................................................................................. 20 4.2.8. Release management and distribution .................................. 20 4.3. SCM schedules .......................................................................................... 21 4.4. SCM resources .................................................................................................................. 21 4.5. SCM plan maintenance ................................................................................................. 21
- 5. Adapting the plan .................................................................................................................. 21 List of figures Fig. 1 Configuration activities overview ...................................................................................... 7 Fig. 2 CM organization .................................................................................................................... 9 Fig. 3 Software project folder structure .................................................................................... 15 Edition: 2 / 2013-02-18 Page 3 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
- 1. Introduction 1.1. Purpose The purpose of this document is to provide an generic software configuration management plan (SCMP) which is applicable to all TK 250 software projects and takes in account the internal MGPI quality management, the MGPI software structure and the software development process, following IEC 60880 (see /2.5/).
This plan defines CM activities, techniques, responsibilities, resources and processes used in the various software development phases for the TK 250 measuring system and its software (firmware).
Relevant and important quality assurance aspects related to the different CM activities are described and defined in the software quality assurance plan (SQAP), re to /1.4.
This software configuration management plan is compliant to the IEEE 828 TM -2005 standard, ref
/2.4/.
1.2. Scope The scope of this document is the identification of a top-level configuration management plan for the software development process of the TK250 system.
This plan describes a required minimum of CM activities, which have to be carried out for TK 250 software projects. Responsibilities, techniques and methods for these CM activities are defined and described in this SCMP.
The CM organization, the resources and the configuration control structures are listed and described.
This software configuration management plan applies to the software of those TK 250 systems (channels), which are designed for the use in IEC 61226 category A or 1E applications. It is thus applicable for the software of the following neutron flux monitoring channels and variations of these channels: DAK 250, DGK 250, DWK 250, DMK 250, DSK 250 and DLK 250.
Doc.-No.: 0348665 A6OE Edition: 2013-02-18 22 /I 2013-02-18 Page 4 Page of 21 4 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
- 2. References, Abbreviations and Acronyms 2.1. References
.2.1.1. MGPI internal documents 11.1/ Quality management manual (QMM) Doc.-No. 0348 250E ed7
/1.2/ Process description Doc.-No. 0348 250 B20E ed4
/1.3/ Requirements and procedures for Class-I E-Equipment Doc.-No. 0348 591 A50E edl
/1.4/ Software quality assurance plan (SOAP) Doc.-No. 0348 664 A60E ed4
/1.5/ Software handover protocol Doc.-No. 0348 121E
/1.6/ Guidelines and rules for the software archive Doc.-No. 0348 074 A61 E ed2
/1.7/ Requirements for technical documentation Doc.-No. 0348 585 AGE ed2
/1.8/ Code review check list for TK 250 software Doc.-No. 0348 662 L60E edl
/1.9/ Procedure for tracking software defects Doc.-No. 0348 663 A60E edl
/1.10/ Software verification and validation plan (SWP) Doc.-No. 0348 666 A60E ed2 2.1.2. General quality procedures and instructions
/2.1/ Quality managements systems - requirements DIN EN ISO 9001 - 2008
/2.21 Quality assurance requirements KTA 1401 - 1996
/2.3/ NRC Regulations (Nuclear Regulations) 10 CFR 50 App. B
/2.4/IEEE Standard for SCM Plans IEEE Std. 8 2 8 TM - 2005
/2.5/ IEC Standard for software in nuclear power plants IEC 60880:2009 2013-02-18 Page 5 of 21 Doc.-No.: 0348665 A6OE Edition:
Edition: 22 // 2013-02-18 Page 5 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 2.2. Abbreviations and Acronyms AAW work instruction (Arbeitsanweisung)
CCB configuration control board Cl configuration item CM Configuration management DCI Document CI MGPI Mirion Technologies (MGPI H&B) GmbH (manufacturer / supplier)
OAW organization instruction PDP Project development plan PTM Project traceability matrix QAP quality assurance plan QMM quality management manual QMS quality management system SC safety class SCI Software Cl SCM Software configuration management SCMP Software configuration management plan SM Software manager SQA software quality assurance SCR software change request VAW process instruction (Verfahrensanweisung)
Doc-No.: 0348665 A6OE Edition: 2013-02-18 22 /I 2013-02-18 Page 6 Page of 21 6 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
- 3. Overview 3.1. CM overview The general CM activities are shown in figure 1 below. The activities and the responsibilities are described in the different chapters of this document. A raw software organization of the TK 250 measuring system is provided in chapter 3.2 of this document.
SCM Identification
- Assign unique designator to
- Identification identify project and SW-baseline
- Control " Verify project identification for
- Status accounting SCIs and DCis
- Reviews / Audits
- Assign tracking number to
- Tracking change request
- Distribution " Establish and list all Cis (software, documents, etc.)
Control
" Place all Cis in the project folder, thereby providing physical control SQA
- Process all CI requests
" Deliver software releases from controlled CIs and change 0 V&V requests and thus ensuring data 0 Monitor integrity 0 Evaluate Audits 0 Certify Status accounting
- Receive/Create and place Cis (documents, technical data, etc.)
to the correct place
- Generate status reports (schedule data, metrics, QA reports, etc.)
Reviews / Audits PreparelSuppotlPerform QA reviews Prepare/Suppot/Perform technical reviews and audits
[I Tracking Consistence-, conformance-tracking of all CIs 0 Ensure completeness of all CIs Interface control Identification, clarification and definiton of all interfaces Release and distribution 0 Distribution and release of a corect, compliance and copmlete software baseline Fig. I Configuration activities overview 21 Doc.-No.: 0348665 A6OE Edition:
Edkion: 2013-02-18 22 /I 2013-02-18 Page 77 of Page of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 3.2. Software organization The TK 250 system is a measuring system used to measure nuclear radiation for radiation monitoring systems or reactor protection systems. The TK 250 system is a multi-processor system which contains different processor boards:
For example: 1 main processor board NZ12 1 ... 2 IO processor board(s) NZ21 1.. .2 V24-interface board(s) NK21 Each processor board is equipped with a microcontroller [ program- and data memory and application specific periphery circuits. The different processor boards are interconnected over one serial bus, the S-Bus.
((
))i Edition: 2 / 2013-02-18 Page 8 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
- 4. The software configuration management plan 4.1. SCM management In this chapter the organization, the roles and the responsibilities for all described SCM activities in this plan are defined and documented.
4.1.1. Organization The complete and current organization of the Mirion Technologies (MGPI H&B) GmbH is shown in the company organization chart in the QMM, see /1.1/ §2.4.
The organization within a project, the individual responsibilities of the project teams and the team members are described in the Project Development Plan (PDP) and the SQAP (see /1.4/). The general CM organization for the CM responsibilities of a typical IEC 61226 category A TK 250 software development project is shown below:
[I:
1]
Fig. 2 CM organization The TUV is involved in the software development process and the different configuration management (CM) activities as an external and independent authority. The TUV and the V&V manager are part of the configuration control board (CCB) and the system and software test group (SSTG). The exact responsibilities for the CM activities are defined in the project specific PDP. The general responsibilities within the CM organization are described in chapter 4.1.2 in this document.
The Project manager is responsible for the communication with the customer. All managerial or technical requests from or to the customer are linked over the project manager.
Doc.-No.: 0348665 A6OE Edition: 2013-02-18 22 // 2013-02-18 Page 9 Page of 21 9 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
For the specific CM activities as described in this SCMP the following responsibilities are defined:
>PM - Project manager
> QM - Quality manager
>SM - Software manager
> CCB - Configuration control board
> SWDG - Software development group
> SSTG - System and software test group 4.1.2. SCM responsibilities For the listed CM activities in chapter 4.2 the following responsibilities and the assigned tasks are described below.
4.1.2.1. Software manager (SM)
The software manager is responsible for managing and maintaining the CM activities. If needed further CM actions are defined and organized by the SM. The general responsibilities of the software manager are to control changes in the software and documentation, and to ensure /
organize testing and verification of the correct released versions and revisions in conjunction with the V&V manager. The software manager is responsible for the following CM activities:
))
4.1.2.2. Project manager (PM)
The project manager shall be involved in or informed about all planning-, developing- and evaluation-activities as defined in this SCMP. The PM should be part of the CCB. The PM is responsible for:
ii:
1]
2013-02-18 Page 10 of 21 Doc.-No.: 0348665 A6OE Edition:
Ediition: 22 /I 2013-02-.18 Page 10 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 4.1.2.3. Configuration control board (CCB)
The CCB has the responsibility to monitor, review, evaluate and authorize all SCM tasks and Cis.
For this reason the CCB consists of different members, but not all members are needed for all controlling tasks. The CCB may consist of the QA Manager, PM, V&V Manager, TUV or even other project member. The CCB tasks are listed below.
1]
4.1.2.4. Quality manager (QM)
The quality manger in conjunction with the software manager is responsible for the completeness consistency of all CIs in a software baseline and makes sure that all documents are conform to the quality assurance process. The QM has the following responsibilities:
1]
4.1.2.6. Software development group (SWDG)
The software development group is responsible for the correct specification, design and implementation of all requirements. The software development takes place on the isolated software development network. The exact tasks are:
((
4.1.2.6. Software and system test group (SSTG)
The software and system test group is a separate organization from the software development group. This group consists of the TOV and the internal test field department ("Priffeld'). The V&V manager, which is also part of the SSTG, is responsible for the test planning and the complete and correct test execution. The planning and execution of the tests is supervised by the TOV. The system and software test group has the following responsibilities:
of 21 Doc.-No.: 0348665 A6OE Edition:
Edition: 2013-02-18 22 // 2013-02-18 Page 11 Page 11 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
((]
4.1.3. Applicable policies, directives and procedures The repository of the software files are placed on an isolated local area network, which is only accessible by the software manager and SWDG members. For this reason the access to the software files is inherently limited.
The files must be placed, named and changed following the rules described in section 4.2 of this document.
The project specific traceability matrix PTM contains a column, in which the listed CIs are assigned to the different responsible project team members: i.e. who is responsible for which Cl.
4.2. SCM activities In this section a minimum of required tasks to manage the software configurations of the TK 250 software system are defined and described.
The activities for the CM are defined as follows:
- 1. Configuration identification
- 2. Configuration control
- 3. Configuration status accounting
- 4. Configuration evaluation and reviews / audits
- 5. Tracking
- 6. Interface control
- 7. Subcontractor / Vendor control
- 8. Release management and distribution 4.2.1. Configuration identification All relevant configuration items (CIs), which are part of a software configuration, must be identified and the physical und functional characteristics must be specified.
The control strategy for those documents must be described. All CIs must be identified, listed and the naming conventions specified. Each CI and its different versions must be uniquely named and the strategy to track, store and retrieve a Cl must be specified. The activities for the configuration identification are described in the following subchapters below.
4.2.1.1. Identifying configuration items
[I Doc.-No.: 0348665 A6OE Edition:
Edition: 2013-02-18 22 /I 2013-02-18 Page 12of21 Page 12 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 4.2.1.2. Acquiring configuration items 4.2.1.2.1. Naming of software configuration (baseline)
Each software-baseline for a processor board with its EPROM parameter section is uniquely identified by a unique software identification number.
The software identification number is used to identify:
((
1]
The document "Explanation of software article numbers", ref to /1.11/ shall be respected for the software identification.
The complete software identification number is part of the EPROM parameter configuration section of the processor-board and is stored in ASCII format in the EPROM. Therefore the software identification can be shown on the display of the main processor-board and can be read via the serial computer interface board NK21 (NZ12 SW-ID only) of the signal channel.
((
1]
Since the executable content of a EPROM consists of a program code section and a EPROM parameter section, the identification number of this software as well consists of two components:
((
))
Edition: 2 / 2013-02-18 Page 13 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
Example of a complete software identification with configuration identification number:
Each part of the complete software identification number is separated by a space, except for the change index of the configuration number.
Note:
With an increment of the change-index of the software identification number the structure of the configuration parameters must be unchanged or must be at least upward compatible.
4.2.1.3. Naming configuration items The naming convention for the CIs differs for the source code elements, the resulting executable files and the related documents.
The folder structure of a software project is shown in the following diagram. All CIs must be stored within these subfolders. The project folder is named by the project name (customer name and / or project name) and the MGPI internal project number.
All CIs of a software baseline must be stored within this folder structure and listed with the correct version of the document in the project specific traceability matrix (PTM). This PTM is used to identify all related CIs to a software baseline.
Doc.-No.: 0348665 A6OE Edition: 2013-02-18 22 // 2013-02-18 Page 14of21 Page 14 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
((
Edition: 2 1 2013-02-18 Page 15 of 21 Doc.-No.-. 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP)
The versioning system for the software is based on the folder structure shown in figure 3 and the software identification numbering scheme (SW-ID and change index).
((
))
of 21 Doc.-No.: 0348665 A6OE Edition: 2013-02-18 22 /I 2013-02-18 Page 16 Page 16 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 4.2.1.4. Naming of software files All software files are named following the naming convention as described in the explanation below. Other file naming conventions are not allowed.
[I
))
4.2.1.5. Naming of resulting software files The resulting software files (( )) are named, stored and archived following the structure as described below. These resulting software files are then archived as described in /1.6/. Additionally changed software files must also be archived. The SM is responsible for the correct and complete archiving procedure of all software files. The resulting files must be stored in a separate subfolder within the configuration folder of the project folder structure until these files are archived as described in /1.6/, the write protection of all these files must be activated.
Edition: 2 / 2013-02-18 Page 17 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 11 1]
4.2.1.6. Naming of documents The versioning system for the documentation and the naming convention of the documentation (requirement documents, specifications, test plans and protocols, etc.) is based on the '/AW 0348 585 A6", ref to /1.7/. All documents must be placed within the sub-folder "Docs" in the project folder on the isolated software network. All released documents must be delivered to the QM department.
The delivering procedure and the archiving procedure are organized by the QM department and governed by the QMM, see /1.1/.
4.2.1.7. Release of software files
((
1]
4.2.1.8. Release of software documentations The release procedure for software documentations - including versioning, control strategies and signature - is defined and described in VAW 0348585 A6 (see /1.70.
4.2.1.9. Release of a production software baseline
))
4.2.1.10. Tools and tool versions All used translation tools (compiler, linker, etc) for a software baseline must be documented with their exact version. The list of used tools shall ensure the possibility to reproduce the executables correct and exact. For this reason a list of all translation tools must be included in the project specific traceability matrix (PTM).
A software version specific information file (*.INF) shall be established and shall be located in the software folder (i.e. source code file folder). Itshall list the software version (software identification number), the version of the used translation tools, the EPROM checksum and the corresponding software (for example the NZ 12 information file lists the SW-ID of the corresponding NZ 21 software; and vice versa).
Edition: 2 / 2013-02-18 Page 18 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 4.2.2. Configuration control 4.2.2.1. Requesting changes A software change request (SCR) must be documented. The document must provide information about:
> Software (software identification + EPROM parameter number) where the change is required
> Requesting person
> Request date
> Request responsible for evaluation, implementation and verification
> Reason for the change request
> Description of the change request
> Urgency of request
> Status of request
> Resulting new software identification and delivery date A software change request form should be used to document and track the SCR.
4.2.2.2. Evaluating changes A software change request must be evaluated by the software manager and the CCB. The needed actions for this SCR are defined and the responsible for this SCR is specified. If the change request results in a change of any requirement or a new requirement, the requirement must be listed in the requirement traceability matrix. The changed version of all CIs must be documented in the project specific traceability matrix (PTM).
4.2.2.3. Approving changes The needed changes and the resulting software baseline are identified by the software manager.
The effects of the changes to the project (software, resources, timing) must be identified and approved by the software manager and evaluated by the CCB. A final decision for the implementation strategy is made by the software manager, the PM and the CCB.
4.2.2.4. Implementing changes The implementation and the verification strategy of a SCR must be identified by the software manager and implemented by the SWDG. All changed CIs must be reviewed, verified and validated as described in this plan and the SQAP, see /1.4/. Test cases must be adapted to the changes resulting from the SCR or new test cases must be created to test the new requirements.
4.2.3. Configuration status accounting The status of all CIs of a baseline is recorded in the project specific traceability matrix (PTM). The traceability matrix contains information about the approved version of each Cl, the status of configuration items and the implementation status. This project specific traceability matrix is tracked during the different QA reviews to identify the correctness and completeness of the CIs for the software baseline. The software manager is responsible for the correctness and completeness of the PTM.
21 Doc.-No.: 0348665 A6OE Edition:
Edition: 2013-02-18 22 /I 2013-02-18 Page l9of Page 19 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 4.2.4. Configuration evaluation and reviews All changed Cis must be reviewed as described in the SQAP, ref /1.4/. Thereby the review procedure differs for software files and documentation files (e.g. specifications, design documents, etc.). All changes in the software or the EPROM parameter section must be approved by the corresponding V&V activities; see also SWP /1.10/ and SQAP /1.4/. V&V activities shall be done on correct released software versions. The version shall be documented in the different V&V plans or protocols and is listed within the project specific traceability matrix (PTM).
4.2.6. Tracking Tracking of the completeness of the different CIs is done at the end of each project phase. The project specific traceability matrix (PTM) is used to check the completeness of the outcomes of the related project phase. The tracking activities are executed as part of the QA review at the end of each development phase. Additional tracking procedures may defined project specific.
4.2.6. Interface control For each application specific channel and its set of EPROM parameters an interface specification shall be established. It shall specify the properties of the binary, analog and digital interfaces of the channel. This interface specification document must be created for each new software and new set of EPROM parameters. It lists the software baseline (SW-ID) and describes the physically structure of all interfaces of a TK 250 signal channel. All interfaces must be tested during the V&V activities, 4.2.7. Subcontractor / Vendor control See SQAP, /1.4/.
4.2.8. Release management and distribution Each new software version and its EPROM parameter section will be released, only if all CIs (documents, source code files, etc.) are correct and complete. All verification and validation activities must be successfully finished. The software is released through the software handover protocol (see /1.50, which documents the software identification number, processor board, etc.;
see also SQAP /1.4/.
The PTM is tracked during the different QA reviews and must be tracked again for the software release to ensure completeness of the software baseline.
A complete software release is done by the software manager in conjunction with the QM and the PM. The checksum of all software Cis is calculated and stored, to identify and verify the correctness of the software CIs. The checksum will be used to check the integrity of the software files. All CIs must be archived as described in /1.1/ and /1.6/.
21 Doc.-No.: 0348665 A60E Edition:
Ediltion: 2013-02-18 22 // 2013-02-18 Page 20 of Page 20 of 21 Doc.-No.: 0348665 A60E
Non-proprietary Version Software configuration management plan (SCMP) 4.3. SCM schedules All Software configuration management activities and the span of the entire lifecycle of the software development will be scheduled within the project time schedule plan. All SCM activities are listed and described in the PTM or PDP.
A software development project will consist of the following phases:
> System requirements specification
> Software requirements specification
> Design
> Module specification
> Implementation
> Module tests
> Integration tests
> Validation tests
> Closeout (software release and distribution)
The closeout phase of the software will include the archiving of the source code files and the documentation files. The distribution of the software should be listed as a milestone within the schedule plan.
4.4. SCM resources Resources are the totality of computer hardware, development software (compiler, etc.), personnel, documentation, supplies, and services applied to a given effort.
The resources for the project and the CM activities are defined by the PM, the software manager, the CCB and the different department leaders. The personal resources are planed within the project schedule plan.
4.5. SCM plan maintenance SCMP maintenance is necessary to document configuration management activities throughout the software's life cycle. If any procedures defined in this document are changed, those changes will be reflected in this SCMP, as needed. Changes of the SCMP must be reviewed as described in the SQAP, ref. /1.4/, by the CCB. Each change on a released version must increment the edition of the document and has to be listed in the change history of this document.
It is the software manager's and development team members' responsibility to ensure the compliance to this plan. It is the responsibility of the software manager, to monitor the SCMP compliance, and ensure that changes and updates are reflected in the SCMP, as required. The SCMP should be reviewed by the software manager at the start of a project, to make sure, that this SCMP is applicable to the project and the present organization of the project.
- 5. Adapting the plan This software configuration management plan is a basic generic SCMP for all TK 250 system related software changes or the creation of a new set of EPROM parameters for the different signal channel types as described in chapter 1.2 of this document. This SCMP shall be applicable for these types of projects.
In any cases or projects a specific SCMP may be created to adapt this plan to project specific requirements related to the SCM activities, responsibilities or other concerns. In this case the software manager is responsible for this project specific SCMP.
Edition: 2 / 2013-02-18 Page 21 of 21 Doc.-No.: 0348665 A60E
1411 -r- of ý4)
Non-proprietary Version P
MGPOI18B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany I I This is a non-proprietary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary Information are indicated by two opening and two closing brackets as shown here: a ))
ýA Software coding rules for TK 250 Systems Copynght 2013. Mirion Technologies (MGPI H8B) GmbH All rights, including rights patent and registered-design rights. where applicable, reserved Transmittal. reproduction, or utilization of this document or disclosure of its contents without expressed authorization by the copynrght holder are prohibited. Violators shall be held liable for dam ages.
Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 MOnchen Fax: +49 (0)89 51513-169 Examin. of contents: -"q Author: MGPI-SW, TBe 7"' Doc-No. 0348662 A60E Formal release: Page 1 of 19 Edition 2 / 2013-02-18 Wtreilung E-1310058 File: Y:ITK?50-SN QA'_oding Rues\Edition 2",o*afl re Coding Rules J34E662 AS0E ed 2.docx
Non-proprietary Version TK 250 - Software Coding Rules
(( 1]
List of Revisions Revis Date Scope of Revision Section /
ion page Draft 2011-11-18 Draft version all Rules for nested structures moved from chapter 4.11.3 to Ch. 4.11.2 chapter 4.11.2 and 4.11.3 Oh. 5.2 6.2 Added rules for module structure and 1 2011-11-23 Added rules for loops and branches Ch 4.11.3 Requirement concerning non conformance added to Oh. 1.3 chapter 1 Added rules concerning the in-and outputs of the function Ch. 6.5 References in chapter 2 translated into English. Corrections 2 2013-02-18 in reference /2.2/ concerning the reference number (/2.1/ --- Chapter
/2.2/) and the number of the referenced standard (60880 -- 2.1 61226).
- 4. t *1*
i 4-i Page 2 of 19 Doc.No. 0348662 A6OE Edition: 201 3-02-18 22 // 2013-02-18 Page 2 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
((1))
Table of Contents
- 1. Introduction ................................................................................................................................. 4 1.1. Purpose ............................................................................................................................ 4 1 .2 . S co p e ............................................................................................................................... 4 1.3. Non conformance .................................................................................................... 4
- 2. References ................................................................................................................................. 5 2.1.1. Documents from MG PI .......................................................................................... 5 2.1.2. General external references .................................................................................. 5
- 3. Abbreviations and definitions ................................................................................................. 6
- 4. General Coding Guidelines .................................................................................................... 7 4.1. Directory Layout ...................................................................................................... 7 4.2. Build Tools ........................................................................................................................ 7 4.3. Build Process .................................................................................................................. 7 4.4. Warnings ......................................................................................................................... 7 4.5. Grandfathering ................................................................................................................ 7 4 .6 . No Tric ks ......................................................................................................................... 8 4.7 . Inte rru p ts ......................................................................................................................... 8 4.8. Operating system .................................................................................................... 8 4.9. File Nam ing conventions ............................................................................................ 8 4.10. Naming conventions for variables and parameters .................................................... 9 4.11. Software structure .................................................................................................. 9 4.11.1. System level ..................................................................................................... 9 4.11.2. Module level .................................................................................................... 10 4.11.3. Function level .................................................................................................... 10 4.12. Self supervision ........................................................................................................... 11
- 5. Coding Rules(( I] ................................................................................................... 12 5.1. File Names ..................................................................................................................... 12 5.2. Module structure ............................................................................................................. 12 5.3. File Header ..................................................................................................................... 12 5.4. Includes .......................................................................................................................... 13 5.5. Function header ............................................................................................................. 14 5.6. Function structure ........................................................................................................... 14 5.7. Code style ...................................................................................................................... 14 5.8. Commentary standard ............................................................................................... 15
- 6. Coding Rules for Assem bler (( ] ............................................................................. 15 6 .1 . F ile Na me s ..................................................................................................................... 15 6.2. Module structure ............................................................................................................. 15 6.3. File Header ..................................................................................................................... 16 6.4. Includes .......................................................................................................................... 17 6.5. Function header ............................................................................................................. 17 6.6. Function structure ........................................................................................................... 17 6.7. Code style ...................................................................................................................... 17 6.8. Commentary standard ............................................................................................... 18 6.9. Rules for assembly language .................................................................................... 18 Edition: 2 / 2013-02-18 Page 3 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( ))
- 1. Introduction 1.1. Purpose The purpose of this document is to provide general coding rules, commentary standards and code layout standards for the PLM programming language and the Assembler programming language used for all processor boards with software (NZ12, NZ21 and NK21) within a TK 250 measuring system.
All rules described in this document are generally tailored for ((
1] but may also be used partly for other programming languages and micro-processors.
The main goals of these coding rules are to improve the quality and correctness the developed software code. Additional goals of the coding rules are:
- Understandable and easier readable code
- Modifiable program code
- Uniform code
- Guidelines for the code implementation
- Better code quality through defined rules
- Verifiable program code (code review)
The coding rules shall help to reduce the number of software faults!
1.2. Scope The coding rules, which are provided by this document, have to be applied to all new software and also to all software modifications on all processor-boards (NZ 12, NZ 21 and NK 21).
These coding rules shall be applied to all software parts which are designed for the use in IEC 61226 category A or 1 E applications. It is thus applicable for the software of the following neutron flux monitoring channels and variations of these channels: DAK 250, DGK 250, DWK 250, DMK 250, DSK 250 and DLK 250.
This document lists and defines the required coding rules, describes additional recommend-dations and outlines various tips for the software implementation.
1.3. Non conformance Any non conformances of the produced code against the design rules should be justified.
Page 4 of 19 Doc.No. 0348662 A6OE Edition: 2013-02-18 22 // 2013-02-18 Page 4 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules 11 11
- 2. References 2.1.1. Documents from MGPI
/1.1/ Software Configuration Management Plan (SCMP) Doc.-No. 0348 665 A60E edl
/1.2/ Process description Doc.-No. 0348 250 B20E ed4
/1.3/ Quality management manual (QMM) Doc.-No. 0348 250E ed7
/1.4/ Requirements and procedures for Class-i E-Equipment Doc.-No. 0348 591 A50E edl
/1.5/ Software quality assurance plan (SQAP) Doc.-No. 0348 664 A60E ed4
/1.6/ Software handover protocol Doc.-No. 0348 121E
/1.7/ Guidelines and rules for the software archive Doc.-No. 0348 074 A61 E ed2
/1.8/ Requirements for technical documentation Doc.-No. 0348 585 A6E ed2
/1.9/ Code review check list for TK 250 software Doc.-No. 0348 662 L60E edl
/1.10/ Procedure for tracking software defects Doc.-No. 0348 663 A60E edl
/1.11/ Software verification and validation plan (SWP) Doc.-No. 0348 666 A60E ed2
/1.12/ SW QA-Manual Doc.-No. 0348 548E ed2 2.1.2. General external references
/2.1/ IEC Standard for software in nuclear power plants IEC 60880:2006
/2.2/ IEC Standard for Classification of I&C functions IEC 61226:2009 Page 5 of 19 Doc.No. 0348662 A6OE Edition:
Edition: 2013-02-18 22 /I 2013-02-18 Page 5 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( 1]
- 3. Abbreviations and definitions AAW Arbeitsanweisung (work instruction)
CCB Configuration control board Cl Configuration item CM Configuration management DCI Document Cl MGPI Mirion Technologies (MGPI H&B) GmbH (manufacturer / supplier)
OAW Organisationsanweisung (Organization instruction)
PDP Project development plan PTM Project traceability matrix QAP Quality assurance plan QMM Quality management manual QMS Quality management system SC Safety class SCI Software CI SCM Software configuration management SCMP Software configuration management plan SM Software manager SQA Software quality assurance SCR Software change request VAW Verfahrensanweisung (Process instruction)
Edition: 2 / 2013-02-18 Page 6 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
((I))
- 4. General Coding Guidelines 4.1. Directory Layout All files needed to build (compile, assemble, link) the software must-be stored within one folder.
The folder structure used for the software modules and build files is defined in the SCMP, ref.
[I 11 4.2. Build Tools Only build tools from the software archive must be used to build the EPROM image (output file).
The build tools (compiler, assembler, linker and the checksum tools for the EPROM images) must be verified before use. ((
))
4.3. Build Process 1]
4.4. Warnings In the tools (compiler, assembler and linker) the option for generating warnings shall be turned on. A quality requirement is that the code does not cause the assembler / compiler / linker to emit warnings. While some warnings may seem harmless, they often mask larger problems.
Even if a warning is really harmless, many warnings make the message output files complex and long and new warnings are not discovered any more by the software developer. Therefore the code shall not lead to warnings. The message output from the assembler/compiler and linker shall be read carefully after each software build process.
4.5. Grandfathering Because guidelines tend to change over time and most of the TK 250 code is PDS (pre developed software), some older code may not completely comply with this current guideline.
You should leave older code as it is. Bear in mind that there are many various risks on changing pre-developed software. Therefore older software (modules, functions or smaller code blocks like branches or loops) that do not need to be changed for a new requirement or to fix a bug, etc shall be left unchanged. Also comments shall only be added in new or changes code sections.
Edition: 2 / 2013-02-18 Page 7 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
[ 1))
4.6. No Tricks Source code is a language for people, not just computers. An experienced software engineer should understand the purpose and the intention of the function, the module or the piece of code even if he/she is not directly involved in the development process. Difficult code-constructions are not the goal of a good coding practice. Special coding tricks, recursive structures or coding practices only useful to reduce the amount of code should be avoided.
4.7. Interrupts Interrupts should be avoided in the software for a TK 250 system. The software of the NZ 21 and NK 21 processor board must be running sequentially without any interrupts. The software of the NZ 12 processor board may use a timer interrupt for the operating system MTX. For some critical software parts the MTX task switch timer interrupt may be inhibited for a short period of time.
All data transfer interfaces (S-bus, serial communication line, etc) should be implemented in polling mode.
4.8. Operating system As mentioned in the previous chapter the NZ 21 and the NK 21 must execute the whole program in a sequential mode without an operating system or any other scheduler.
The operating system MTX shall be used on the NZ 12 processor software.
4.9. File Naming conventions The naming conventions for source code files used within TK 250 system software are strictly defined. These file naming conventions must be respected. Other naming structures are not allowed.
))
Edition: 2 / 2013-02-18 Page 8 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( ))
4.10. Naming conventions for variables and parameters The following naming conventions for variables are valid:
I]
4.11. Software structure 4.11.1. System level The whole TK 250 program shall be systematically grouped. Each software part should correspond to a specific set of functionalities which belongs to each other.
- Specific system operations shall be implemented in specific software parts (processor, group of modules or module)
- The software should be portioned so that aspects which handle such functionalities as:
o Processor external interfaces o Operating system (scheduler) o Storage allocation and handling o Utility functions o Self test functions o Application software are separated by the module structure
- The program structure should permit new implementations or changes with a minimum of effort
- The software structure should be comprehensible and clearly stated
- The software of a processor should be working sequentially (at least for the NZ 21)
- The software should have an explicit and clear modular structure
- Dynamic changes on the executable code shall be avoided (no self modifying code)
Edition: 2 / 2013-02-18 Page 9 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( 1]
4.11.2. Module level The software of a processor board (NZ 12, NZ 21 or NK 21) shall be portioned in software modules. All software module shall share a common module structure (module header, include files, global declarations, etc - see below for more details).
- Each module shall be clear and intelligible
- Each module should correspond to a specific function or a specific set of belonging functionalities (e.g. self tests)
- The size of a module should not exceed 2000 lines over all (including comment lines, code lines and empty lines). This rule should limit the maximum size of executable instructions and the memory space for the program code in the hex-file per module.
Longer modules are only allowed under special circumstances
- The interface between modules should be as simple as possible and well documented
- The number of module interfaces should be minimized
- The module interfaces should be stated (functions, structures, variables, configuration parameters, user adjustable parameters)
- The usage of a central module library (i.e. generic software modules) is precluded by the software quality standards for TK 250 systems; ref to /1.12/ and the configuration specification.
Nested structures:
- Nested structures shall be handled with care; deeply nested structures should be avoided. The limited size of the stack has to be taken into account.
- Nested macros should be avoided
- The program structure shall be as clear as possible and not obscure the intention of the program 4.11.3. Function level Each module should provide one or more functions (( )) The following rules should be applied during the design and the implementation of new functions or code parts.
Execution time of routines, functions, macros, etc:
- The execution time of a function should be considered (the runtime should be short; code parts with a input data dependent execution time should be short; the influence of physical processes on the behavior of the code should be kept low).
- All functions shall be deterministic.
Edition: 2 / 2013-02-18 Page 10 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules Coding of routines, functions, macros, etc:
- Routines and functions should be organized as simple as possible
- The interface of the function should be clear and predefined
- Routines should have only one entry point
- Routines should return to only one point for each subroutine call Addressing and arrays:
- Simple addressing techniques should be used
- Extensive address calculation should be avoided
- Arrays should have a fixed predefined length
- The array dimension should be fixed and not changed during the runtime Loops and branches:
- Loops should be handled cautiously o Endless loops shall be avoided o Inaccessible loops shall be avoided o There shall be only one exit point of the loop
- Branches should be handled cautiously o Complete decision should be applied (IF ... ELSEIF.. ELSE) o Deeply nested branches should be avoided 4.12. Self supervision The system software must contain self supervision mechanisms. Errors that are detected by the self tests or the plausibility checks shall be reported.
The self supervision should include:
- Plausibility checks
- Memory content shall be protected or monitored
- Read/write protection of parameter-memory
- The parameter transfer should be checked or verified
- Verification of correct program sequence
- Program run time check(s) or verification Edition: 2 / 2013-02-18 Page 11 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( 1]
- Recalculation of the signal processing; should also be performed for intermediate results
- If possible verification of external interfaces
- When addressing an array its bounds should be checked The error checking shall be performed at a detailed code level.
The exact self test mechanisms and the resulting fault messages should be determined in the design phase.
- 5. Coding Rules for (( 1]
5.1. File Names All source code files must be named following the scheme described in chapter 4.9. Only the file-extension (( )) allowed for ((f ] source code files.
5.2. Module structure The module structure must be identical for all software modules used in TK 250 system software.
((
11 5.3. File Header Edition: 2 / 2013-02-18 Page 12 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules 1[ 1]
1]
A standardized file header for a (( )) source code file is shown below.
((
1]
This file header is part of the template (( )) source code file and may be copied from the template and shall be used for new source code files.
5.4. Includes
- All includes should be located at the begin of the module after the file header
- Unneeded includes shall be avoided and/or removed
))
- The include files shall have the file extension (( ))
Page l3of 19 Doc.No. 0348662 A6OE Edition: 201 3-02-18 22 //2013-02-18 Page 13 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( 1]
5.5. Function header Each function within a (( )) 3ource code file must start with a comment block as function header which describes the function and the expected inputs and the output of the function.
The preferred format places the parameter information as comments in the actual definition:
- Funktionsname: *
- Parameter: *
- Beschreibung: *
- Inputs:
- Outputs:
5.6. Function structure Each function should start with a meaningful name. The return value (if any) must be described.
All parameters to the function (if any) must be commented and the expected format, range and the matter must be shortly described.
Each function shall be finished with the key-word 'END' and the function name.
5.7. Code style
- As far as possible and useful; each instruction line should only execute one operation; otherwise this code line must be explicitly commented to identify and justify the code line
- The naming definitions from the file (( )) must be used for the construction of the code sequences; i.e.:
IF (condition) THEN DO ELSE DO END IF Other naming conventions shall be avoided. No additional naming convention shall be defined project-, processor- or module-specific to simplify the code.
- The indentation of code blocks shall be 4 spaces. Code blocks are functions, "IF"-
statements, "FOR"-loops, 'WHILE"-loops, etc. The indentation shall not be done using tabs.
The example shows a typical function structure with the correct indentation:
((i
))
19 Doc.No. 0348662 A6OE Edition:
Edition: 201 3-02-18 22 // 2013-02-18 Page l4of Page 14 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( ))
1]
5.8. Commentary standard As far as useful and practicable each single code construction should provide a comment which describes the intention and function of this code section.
The comment should be provided at the end of the code line or if needed before a new code section starts (i.e. start of a new calculation section, etc) to separate different functionalities from each other.
IF (K GWU TYP(O)= NZ21GW 0 GW) THEN DO /* threshold type = upper limit? */
CALL FPAC NEG; /" invert hysteresis value */
END IF
- 6. Coding Rules for Assembler (( 1]
6.1. File Names All source code files must be named following the scheme as described in chapter 4.9. Only the file-extension (( 11allowed for assembler source code files.
6.2. Module structure The module structure must be identical for all software modules used in TK 250 system software. The source code file template for (( 1] should be used for the creation of new software modules. If a module is changed, the structure of the template should be used (see also chapter 4 and especially chapter 4.5).
The following module sequence structure should be applied for ASM modules:
19 Doc.No. 0348662 A6OE Edition:
Edftion: 22 //2013-02-18 2013-02-18 Page iSof Page 15 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( 1]
6.3. File Header Each (( 1] source code file must contain a file header with information about:
((
1]
A standardized file header of a [f )) source code file is shown below:
[I 1]
This file header is part of the template (( ]J source code file and may be copied from the template and shall be used for new source code files.
Edition: 2 / 2013-02-18 Page 16 of 19 Doc.No. 0348662 A60E
TK 250 - Software Coding Rules Non-proprietary Version 6.4. Includes
- All includes should be located at the begin of the module
- Unneeded includes shall be avoided and/or removed
- The include files should have the file extension (( )) for port definition files.
6.6. Function header Each function within an (( 1] source file must start with a comment block as function header which describes the function and the expected inputs and the outputs of the function. The meaning, the storage type and the data type of the in- and outputs should be described.
The preferred format places the parameter information as comments in the actual definition:
- Funktionsname
Beschreibung:
- Inputs:
- Outputs:
- 6.6. Function structure Each function should start with a meaningful name. The output values (if any) must be described. All input values to the function (if any) must be commented and the expected format, range and the matter must be shortly described. Each function shall be finished with the key-word 'RET'.
6.7. Code style
- As far as possible and useful, each instruction line should only execute one operation
- The construction of the code sequences shall be uniform, well arranged and the code sequences or functions should be as short as possible. The following code section shows a typical assembler code sequence. The instruction and the data for the instruction should be separated by minimum 4 spaces; or even more if useful or needed to improve the clarity of the code section.
))
Edition: 2 / 2013-02-18 Page 17 of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules LL ))
6.8. Commentary standard As far as useful and practicable each single code construction should provide a comment which describes the intention and function of this code section.
The comment should be provided at the end of the code line or if needed before a new code section starts (i.e. start of a new calculation section, etc) to separate different functionalities from each other.
1))
6.9. Rules for assembly language Because assembly language is machine code and not easy readable / understandable at all, the following additional rules shall be respected when coding in assembler (chapter 4.5 is also valid for these rules).
- Branching instructions using address substitution should not be used
- Branch table contents should be constant
- All indirect addressing should follow the same scheme
- Indirect shifting should be avoided
- Multiple substitution or multiple indexing within a single machine instruction should be avoided
- The same macros should always be called with the same number of parameters
- Labels should be preferable used to make references within the code
- Numerical values (absolute addresses or relative offsets) should be avoided
- Subroutines should preferable be called using the key-word "CALL"
- The return address from a subroutine should be directly after the subroutine call instruction Doc.No. 0348662 A6OE Edition:
Edition: 2 /2013-02-18 2 / 2013-02-18 Page 18 of 19 Page l8of 19 Doc.No. 0348662 A60E
Non-proprietary Version TK 250 - Software Coding Rules
(( 1]
- Parameters for a subroutine should be set directly before the subroutine is called (or in a subroutine which is executed before the called subroutine)
- Assembler instructions shall not be renamed (naming definitions of instructions, etc)
- The usage of macros should be clearly recognizable and stated Doc.No. 0348662 A60E Edition: 2013-02-18 22 / 2013-02-18 Page 19 Page of 19 19 of 19 Doc.No. 0348662 A60E
1ll /7-I-- It Non- proprietary H&B Muni ch pl ant Type test doc. no. 48 TOV N orddeutschl and INSPECTION CERTIFICATE for DIGITAL WIDE-RANGE CHANNEL DVW( 250 SOFTWARE Certificate no.: 1225068496101 Type of inspection: T ype testing according to KTA 3505 (11.84)
Designation of the tested Softwre NZ1 2, vers. DV'A(250 3100 347 B equipment: So ftvare NZ21, vers. DVK250 3100 350 B Softvwre NK21, vers. 3100 342 B Manufacturer: Hartmann & Braun AG, Munich Assodated documents: See "Technical test report for DIGITAL WIDE-RANGE CHANNEL DV4(250 SOFTWARE" published by TUV Norddeutschland e.V. on 1990-08-16 Requirements: See "Technical test report for DIGITAL W1DE -RANGE CHANNEL DWK250 SOFTWARE" published by TUV Norddeutschland e.V. on 1990-08-16 Inspection location: Hamburg Inspection date: May 1989 -April 1990 Inspectors: E .-U. Mainka and H. Mehrgardt Inspection result: The inspection v'as passed in accordance vPth the "Technical test report for DIGITAL WIDE-RANGE CHANNEL DVVAK250 SOFTWARE" as published by TUV Norddeut schland e.V. on 16f8/1990 Hamburg, 1990-08-16 TUV Norddeutschland e.V.
Inspectors: .r.
Mainka Mehrgardt
A41 -F- 0 ?(k)
Non-proprietary Version H&B Munich plant Type test doc. no. 48 Section for computers and microprocessor systems TUV Norddeutschland Technical test report for DIGITAL WIDE-RANGE CHANNEL DWK 250 SOFTWARE produced by Hartmann & Braun AG, Munich Hamburg, 16. August 1990 PBDWK250_Software_160890 I
This is a non-proprietary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( ))
Non-proprietary Version TOV Norddeutschland Table of contents Introduction
- 1. Test object
- 2. Test basis
- 3. Documents and equipment components submitted for testing
- 4. Test specification 4.1 Specification test 4.2 Recording of hardware-based boundary conditions 4.3 Analysis of control flow and data flow with test tools 4.4 Verification 4.5 Global test of hardware and software
- 5. Test execution 5.1 Testing of NZ21 5.1.1 Specification test 5.1.2 Recording of computer hardware with the HARDWAREDEFINITION tool 5.1.3 Tool-based check for formal implementation criteria (control and data flow analysis) 5.1.4 Tool-based static program analysis 5.1.5 Dynamic tests with real-time emulator 5.2 Testing of NZ12 5.2.1 Specification test 5.2.2 Recording of computer hardware with the HARDWAREDEFINITION tool 5.2.3 Tool-based check for formal implementation criteria 5.2.4 Code inspection 5.2.5 Black box and white box function tests 5.3 Testing of NK21 5.3.1 Specification test 5.3.2 Recording of computer hardware with the HARDWAREDEFINITION tool 5.3.3 Tool-based check for formal implementation criteria 5.3.4 Tool-based static program analysis 5.3.5 Black box function tests 5.4 Global system test
- 6. Recurring tests
- 7. Summary of test results and recommended hardware/software changes PB_ DWK250OSoftware_160890
Non-proprietary Version TUV Norddeutschland Appendix Al Post-specification A1.1 Specification NZ21 A1.1.1 List of input/output signals and variables A1.1.2 List of target functions A1.2 List of NZ1 2 target functions A2 Used tools and their results A2.1 Hardware definitions for A2.1.1 NZ21: wapro0.hardwaredok A2.1.2 NZ12: wmproO.hardwaredok A2.1.3 NK21: zvproO.hardwaredok A2.2 Results of disassembler DIS8051 A2.2.1 NZ21: wapro0. rep A2.2.2 NZ12: wmproO. rep A2.2.3 NK21: zvproO.rep A2.3 Results of control flow analyzer CONY A2.3.1 NZ21: wapro0. pro A2.3.3 NK21: zvproO.pro A2.4 Results of structure chart generator STRUCTOR - routines that implement main functions A2.4.1 NZ21: waproO.str A2_4.2 NK21: zvproO.str A3 Directory of results documents generated during testing A3.1 Reference list of variables and variable addresses Reference list of constants in program memory List of main programs and subroutines Commented program lists and structure charts for main programs/subroutines A3.2 NK21: List of main programs and subroutines A4 Example program part with added code and superfluous commands A5 Implemented finite automaton NK21 - serial interface A6 Checklists for specification tests NZ21, NZ1 2, NK21 A7 List of technical data for DWK 250 verified by analyses and tests PB_ DWK250OSoftware_160890
Non-proprietary Version TUV Norddeutschland Introduction Prior to first use of electrical transmitters and transducers for purposes of reactor protection, KTA rule 3505 stipulates that type testing be performed to verify that the relevant equipment complies with the data specified on the data sheet.
TUV Norddeutschland was commissioned by TUV Rheinland to conduct the type testing of the software for the Hartmann & Braun digital wide-range channel DWK250.
The software type testing involved both an analytical and a practical component. The tests were performed by the authorized inspectors E.-U. Mainka H. Mehrgardt The execution of the relevant tests is described in this test report. The test results are also evaluated.
PB_ DWK250_Software_160890
Non-proprietary Version TOV Norddeutschland
- 1. Test object The Hartmann & Braun digital wide-range channel (DWK 250) is designed to measure the neutron flux density in nuclear reactors from the source range to approx. 10% nominal reactor power. Multi-channel redundant configurations are used to generate signals for monitoring and displaying the neutron flux and to trigger the reactor protection system.
The DWK 250 is constructed as a three-processor system on the basis of Intel 8031 microcontrollers.
It consists of the processor modules The object of this inspection is the software of the three DWK 250 processor modules NZ21, NZ1 2 and NK21. (( 1]
The signals and data telegrams travelling into and out of these three modules represent the input/output interfaces for the software functions and their logical behavior is also examined.
The remaining hardware modules of the DWK 250 and their processing functions are not covered by this inspection.
- 2. Test basis The following documents form the basis for the type testing of the DWK 250:
- Offer from TUV Norddeutschland regarding the software type testing of H&B DWK 250 with reference AZ KE 17.3.7 dated 22/2/1989
- Order from TUV Rheinland for the software type testing of H&B DWK 250 with order no.
979/880057/03 dated 13/3/1989
- Order confirmation of TUV Norddeutschland with reference AZ KE 13 dated 6/6/1989
- KTA 3501, version 6/85
- KTA 3505, version 11/84
- DIN V VDE 0801, draft, version 01/90 PB_ DWK250OSoftware_160890
Non-proprietary Version TUV Norddeutschland
- 3. Documents and equipment components submitted for testing
- H&B documents:
H&B designation Short reference: Date Approval mark User manual 5-0106 A70 B 12/4/1990 Specification / technical information 5-0106 D22 Spec 12/4/1990
[C 1]
PB_ DWK250OSoftware_160890
Non-proprietary Version TUV Norddeutschland 1]
Computer interface for SW-CI 13/2/1990 X digital wide-range channel DWK250 5 - 0106 B93 Letter from H&B, EKS-M dated 14/11/1989 Letter from H&B, Bucher/EKE dated 12/12/1989 addressing provisional change notices QA manual for software development, edition I of 14/11/1988
- Document from Preul3enElektra:
KVWW - operating manual El, vol. 11, section "Monitoring reactor performance (neutron flux)", rev.
06/88
- H&B equipment:
Digital wide-range channel DWK 250, cert. no. 5-9736 (corresponds to circuit diagram 5 - 0106 P10 dated 10/1 2/1989)
Serial no. 0589.0.003, FB-no. 525 501 for execution of practical tests PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland
- 4. Test specification The scope and execution of the test comprises the following sub-steps:
- Specification test according to checklists
- Recording of hardware-based boundary conditions
- Computer-based control and data flow analysis
- Verification with decoupling confirmation, black box and white box tests
- Global test The following provides a detailed description of the test scope in the context of the individual sub-steps.
4.1 Specification test The specification test utilises a range of procedures based on the varying inspection depth for the reactor protection functions of NZ21 as well as the other measurement, dialogue and monitoring functions.
For the NZ21 reactor protection functions, a SW (requirements) specification is produced on the basis of the H&B documents listed in section 3. The documentation employed comprises both specification documents and implementation-specific design documents. The SW requirements specification consists of:
- A list of all relevant input/output signals and data at the relevant interface of the test object, as detailed in section 1, and including possible error conditions
- A list of all processing functions linking these input/output signals and data along with the behaviour specified in the manufacturer documentation in the case of improper operation The specification testing of the functions implemented in NZ1 2 and NK21 involves a consistency check of the documents provided by H&B (cf. document directory in section 3).
The test results are documented using the requirements specification and system design checklists from [1] (see also appendix A6).
4.2 Recording of hardware-based boundary conditions This computer-based test step is conducted with the aid of the HARDWAREDEFINITION tool [2] for all 3 processor modules. The results are provided in appendix A2.1 of this test report in the form of the 3 hardware documents of the test tool and list the computer resources addressable via each individual processor bus.
PB_ DWK250_Software_160890
Non-proprietary Version TOV Norddeutschland 4.3 Analysis of control flow and data flow with test tools This test step is performed for the entire software of all 3 processor modules. The following tools are employed:
- PC disassembler [3]
- PC control flow analyser CONY [3]
- PC data flow analyser CONYDAT [3]
The analysis results produced by these tools are extensive [3].
They consist of:
- Formatted, block-oriented program lists
- Metric program specifications
- Control flow representations in the form of overviews, flow charts and NASSI-SHNEIDERMAN diagrams
- Data reference lists, structured by blocks and subroutines.
Appendix A2 of this test report contains the following:
- Metric program specifications
- (Control flow) representations of subroutine calls
- NASSI-SHNEIDERMAN diagrams 4.4 Verification 10 processor (NZ21):
For the analogue interface NZ21, verification of the program parts is performed by means of:
- Checking for formal implementation criteria
- Static analysis of the implemented processing functions on the basis of the results of the tool-based tests [2, 3]
- Verification of decoupling from other program parts
- Testing for possible deadlocks in implemented programs
- Dynamic tests with real-time emulator The test methodology in detail:
For the target functions specified in appendix Al, the entire program code is examined for use of the processor resources - such as ports, registers, control/status bits - linked with the relevant function (as well as listed in the specification and, if applicable, documented with the HARDWAREDEFINITION tool). The usage of all program parts accessing these resources is then monitored across all call levels throughout the program. This ensures that all function-relevant program parts up to main program level are identified. The actual program function is then determined bottom-up on the basis of the disassembled program file, which is not commented by the manufacturer, and compared with the specified target function. The decoupling is checked for the entire program on the basis of the disassembler result files.
PB_ DWK250OSoftware_160890
Non-proprietary Version TOV Norddeutschland Main processor (NZ12) and serial interface (NK21):
For the main processor NZ1 2 and the serial interface NK21, the software test is performed by means of the following:
- Tool-based check for formal implementation criteria
- Code inspection for manual tracing of program functions
- Black box and white box tests of implemented safety-relevant functions (cf. NZ12 function list in appendix 1.2).
An analytical functional verification is not required for the relatively extensive NZ1 2 software since
- with the exception of the coupling with NZ21 reactor protection functions detailed in sections 5.1.1, 5.4 and 6 -this module only features functions corresponding to safety level 3 [1].
The software of the serial interface NK21 for the optional superordinate host computer is analysed with the aid of tools.
The targeted inspection depth for the reactor protection functions is not necessary for NK21 due to its lesser safety-critical significance. In this case, the aim of the analysis is to establish
- The quality of the software according to formal implementation criteria
- The main module functions on the basis of a manual examination of the tool results and the developer documentation 4.5 Global test of hardware and software The system functions specified in appendix 1.1 and 1.2 are subjected to practical testing on the basis of predefined input signals (signal sequences).
When defining the input signals, particular consideration is given to functions affecting the cooperation between the 3 modules (S-BUS communication, interaction of NZ21 and NZ1 2 in the creation of the wide-range and RELFAG (flux change rate) signals (analogue outputs 1 and 2 of NZ21)) as well as their output via NZ21.
Further tests are conducted to examine the function behaviour in the case of simulated hardware faults or module malfunctions. The tested system functions, used test signals and function results are documented.
- 5. Test execution The type testing is initially performed on an individual module basis, i.e. separately for NZ21, NZ12 and NK21. An assessment of the interaction or decoupling of the module functions is provided in sections 5.4 and 7.
PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland 5.1 Testing of NZ21 5.1.1 Specification test The software of NZ21 represents a subsystem within DWK 250. No separate requirements specification was created for this subsystem by H&B.
However, the main characteristics of the implemented DWK 250 programs are described in a clear and comprehensible manner in the documents specified in section 3.
In the context of the specification test, the details in documents U, Spec and SW-* relevant to software function were compiled and grouped into lists of relevant signals/variables and functions (for post-specification see appendix A1 .1). The examination of the manufacturer documents specified in section 3 shows a consistent, complete and systematically structured representation of the implemented computer and meets the assessment criteria for system design documents of safety level 1 pursuant to [1], with the exception of the following points:
Appropriate preventative measures were taken against possible function impairment as a result of this coupling in the form of software revision 2/90, reading back of the discriminator voltage and the verifiable decoupling of the NZ12 binary output.
- Software revision 2/90 enhanced the self-tests for NZ21 specified in document SW-ST21 by the addition of a CPU test that inspects the most important working registers and ports. This addition ensures effective monitoring of all components known to make a noteworthy contribution to the failure rate.
5.1.2 Recording of computer hardware with the HARDWAREDEFINITION tool The recording of the computer hardware using the HARDWAREDEFINITION tool has shown that no access conflicts occur in the component addressing.
PB_ DWK250_Software_160890
Non-proprietary Version TJOV Norddeutschland 5.1.3 Tool-based check for formal implementation criteria (control and data flow analysis)
Testing for compliance with formal implementation criteria produced the following results:
The implemented software is well structured in terms of the following criteria:
- Modularisation, control flow structure
- Use of data storage
- Use of the additional hardware timer on 8031, S-BUS, interrupt logic
- Hiding of local variables Improvements to the control flow structure are possible in the following routines:
- subr035F (calculate correlator signal): 10 subroutine outputs
- subrOl 80 (receive NZ1 2 telegram) 3
- subr0479 (read correlator) 2
- subr0649 (CPU check) 2
- subr0820 (constant addition) 4
- subrO9AB (set limit value) 3
- subr0727/subrO820 Code sharing
- subr0841 /subr0854
- subrOABE/subrOAF3 The safety assessment of the formal improvement proposals is provided in section 7.
5.1.4 Tool-based static program analysis, decoupling verification, testing for deadlocks In the tool-based static program analysis, the NZ21 software was checked for correct implementation of the functions specified in appendix 1.1 as well as decoupling of the reactor protection functions from the self-test and S-BUS transfer functions. The software does not contain any constructs that can lead to deadlocks.
The identified problems listed below have been resolved with software revision 2/90:
- Command assignment of interrupt vector addresses with program code
- Excessively large address range of EPROM test
- No reporting of detected time monitoring errors for S-BUS Even with the revised software, there is still potential for jitter with the check intervals of the correlator voltage and the query times of the counted pulses if sending of the data portion of an S-BUS telegram is started shortly before the end of the time monitoring. This assumes a delayed receipt of a transfer telegram. Taking into account the minimal impact of this jitter on the pulse numbers and correlator voltage due to the signal averaging and the fact that this process is subject to a malfunction of NZ12 or NK21, we can conclude that the mechanism in question will not lead to system malfunctions.
PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland 5.1.5 Dynamic tests with real-time emulator To determine the dynamic behaviour of the software, a real-time emulator was used to test the branch behaviour of the pulse and AC paths (correlator signal path), taking into account the filter functions and limit value formation. Compliance with the processing times specified in the documents B and Spec was successfully verified in these tests.
5.2 Testing of NZ12 5.2.1 Specification test The tasks of the WMPROO software for the main processor NZ12 of the wide-range channel DWK250 are described in the following documents:
((
1]
Examination of these documents showed that the assessment criteria for system design documents of safety level 3 pursuant to [1] are met.
The documents are consistent, complete and systematically structured.
Since technical changes were made over the course of the test, this resulted in inconsistencies between the user manual U and both the specification/technical information Spec and the software documentation SW-*. The documents have since been revised, meaning that they are now consistent and represent the current design state.
((1 PB_ DWK250OSoftware_160890
Non-proprietary Version TOV Norddeutschland
((
11 5.2.2 Recording of computer hardware with the HARDWAREDEFINITION tool With regard to the recording of the computer hardware using the HARDWAREDEFINITION tool, no module hardware deficiencies relevant to software function were identified.
5.2.3 Tool-based check for formal implementation criteria The software is clearly structured, thus permitting simple assignment to the specified task structure.
Limited use is made of the possibility of multiple exits from routines, as implemented in (( 1]
that mainly sinqle-entry/single-exit structures are employed.
Even (( )) source code, the three routines
- Receive and evaluate,
- Read parameter of the measured value task and
- Interpreter of the server task are very large when compared to the other routines and thus more difficult to comprehend. However, the understandability of the code is achieved by the clear structuring of the sub-functions, which is also implemented for these routines. Appendix A2.2.2, disassembler report file, contains details on the implemented routine sizes and number of routine outputs as well as the task call structures, the interrupt routine for evaluating the S-BUS interrupt or timer overflow and the operating system.
PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland 5.2.4 Results of code inspection The code inspection of the (( )) sources showed that front panel operation and computer connection access data and parameters separately and directly (protected by the REGION mechanism):
There is no set of commonly used access procedures, in the sense of an intermediate software layer.
This fact is irrelevant to the correct functioning of the system and, due to the clear software structure, is not to be seen as a significant disadvantage.
A specific effect of the different access options - yet one that was intended by the manufacturer - is the privileging of the V24 user interface over the control panel. According to the rules of structured programming, a single set of operating functions should be used here to manage identical user dialogues of the host and control panel. However, due to the clear structure observed in the code inspection, the decoupled function of both user interfaces is clearly traceable in the software submitted for testing. This effectively rules out the possibility of function-impairing consequences.
From a safety perspective, the saving of parameters and limit values to a copy range in RAM not monitored for data consistency can have a negative impact. With the introduction of SW version 4.90, however, the manufacturer has provided sufficient protection against such value distortions through the cyclical refreshing of RAM data from the monitored CMOS-RAM.
To fully exclude the possibility of invalid setting of test triggers via the binary output of NZ12, the output function must be implemented in a program branch that is analytically decoupled from other software functions. This binary output should therefore be implemented such that it is cyclical, non-interruptible and independent of user tasks.
5.2.5 Black box and white box function tests
- Test structure The black box tests were performed on a DWK250 measurement channel with the following configuration:
1]
PB_ DWK250OSoftware_160890
N on-proprietary Version TOV Norddeutschland Fig. 5.2.1 DWK250 DIGITAL WIDE-RANGE CHANNEL Configuration for function test PB_ DWK250_Software160890
Non-proprietary Version TUV Norddeutschland The following generators were used for the signal input:
- For the pulse input: Philips PM 5132 function generator
- For the AC input: Hewlett Packard HP 3314A function generator The operation of the main processor via the serial interface was tested on a PC using the Hartmann &
Braun test program TEST.EXE dated 22/2/1990. The data transfer between the PC and the serial interface of the DWK 250 was monitored with an ASCII terminal (GRAPHON G0250) to exclude the possibility of test program errors (white box test).
- Test scope According to the specification, the following display and access functions can be called via the control panel and the serial interface:
Control and access overview for DWK250 I]
PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland All specified control and access functions were checked. The consistency of the two access methods via the control panel or serial interface was also examined.
Since no value ranges are specified for many inputs, both physically meaningful entries complying with the specification and meaningless entries, such as negative limit values for pulse rates, were checked.
The process was generally based on the default parameter set (see user manual B).
The input parameters were varied within the specified ranges and beyond. The temporal behaviour was checked through continuous alteration of the input parameters and step inputs (step response).
The output signals on the analogue outputs were monitored. The functions 'Test" and "Parameter' were checked for correct interlocking.
The startup and shutdown lock was checked with different input values.
The filter functions were tested with different parameter sets and the time constants calculated by the channel were monitored.
The transition range was checked with different dynamics and parameter settings.
Fault messages were triggered by means of corresponding input values, hardware separation of signal paths and changes to the checksum in EPROM.
For the send and response messages, the data transfer protocol on the S-BUS was verified with a TEK 1240 logic analyser (white box test).
- Test results With the exception of the following points, the test demonstrated full compliance with the specification:
- With the exception of the following voltage monitoring parameters, a value range of -9999e+/-29 to +9999e+/-29 is possible:
))
PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland 1]
The results of the black box tests highlight the same issues as raised by the specification test (5.2.1).
Thus the black box test results leads to the same conclusions than the specification test.
5.3 Testing of NK21 5.3.1 Specification test The tasks of the software (ZVPROO) for the computer interface V24 of the DWK 250 are fully and clearly described in SW-Cl. According to this specification, the V24 interface implements a data exchange triggered by the optionally connected host computer between it and the control processor NZ1 2 of the DWK 250 - collisions of messages between the host and multiple possible V24 modules can be excluded in this case.
))
5.3.2 Recording of computer hardware with the HARDWAREDEFINITION tool With regard to the recording of computer hardware using the HARDWAREDEFINITION tool, no module hardware deficiencies relevant to software function were identified.
PB_ DWK250_Software_160890
Non-proprietary Version TOV Norddeutschland 5.3.3 Tool-based check for formal implementation criteria The test for compliance with formal implementation criteria showed that the implemented software is clearly structured with regard to the following criteria:
- Modularisation, control flow structure
- Use of data storage
- Hiding of local variables To ensure defined computer behaviour in the case of an incorrectly triggered interrupt, the assignment of the interrupt vector addresses should be as in WAPROO The following points should also be observed by the manufacturer in the case of future software revisions:
- Fragmentation of linear processing paths should be avoided (cf. example in appendix 4).
- In the interest of software simplicity, the simplest available assignment and query commands should be used to implement specific functions (cf. example in appendix 4).
- The following subroutines should contain only one exit:
subr0036 subr008F subr02DF subr0311 Due to the generally excellent structure of the software and in the interest of retaining the current tested version, no immediate changes are required.
5.3.4 Tool-based static program analysis The implementation of the finite automaton detailed in appendix A5, and thus the specified target behaviour of the software, was verified in the program analysis. Appendix 2.4.2 contains structure charts of the main program, the interrupt routine and the S-BUS send/receive routines.
5.3.5 Black/white box function tests The practical testing of the V24 functions was performed together with the NZ12 function tests. The TURBO-PASCAL PC dialogue program specified in section 5.2.5 served as the host, while the specification-based dialogue process between the host PC and NK21 was monitored by an ASCII terminal in transparent mode, as detailed in section 5.2.5.
Testing of the correct S-BUS transfer was performed with the aid of a logic analyser triggered by the V24 software execution.
No problems were identified with the NK21 software in the function tests.
PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland 5.4 Global test Testing of the functions specified under 4.5 returned positive results.
- 6. Recurring tests Using sub-functions of the implemented software, the hardware components mainly contributing to failures of NZ21 and NZ1 2 are subjected to cyclical tests during plant operation and monitored by a watchdog on NZ1 2. Thanks to these online tests, recurring tests do not require any test steps intended to uncover faults on the following hardware components: processor, EPROM, EEPROM, D/A converter and RAM.
The recurring tests should cover components that are not monitored online by the software. This includes in particular: the binary input/output channels and the functions of the manual input/output.
- 7. Summary of test results and recommended hardware/software changes The type testing proved that the software of all three modules (NZ21, NZ12 and NK21) is of high quality, both with regard to the logical, specification-based structuring of functions and in terms of formal implementation criteria. Although no CASE tool was used in its creation, the software design and program source documentation is of a good standard, in some cases even exemplary.
A summary of the functions and technical data verified in our tests of the DWK 250 is provided in appendix 7.
To reliably decouple the reactor protection functions implemented on NZ21 from those on the main processor, as specified by the manufacturer, additional hardware and software measures were implemented which:
- Enable the NZ 12 to detect if incorrect pulse discriminator thresholds have been transferred to the NZ21
- Allow setting of the binary outputs on NZ12 at 50 ms intervals during interrupt lockout only in a defined computer state PB_ DWK250OSoftware_160890
Non-proprietary Version TUV Norddeutschland By masking the test signal output with the test release and forcing simultaneous triggering of the test message, the manufacturer has implemented measures to ensure separation of the NZ12 functions from the NZ21 reactor protection functions.
The cyclical refreshing of safety-relevant parameter and threshold values in the RAM copy range, which is not monitored for data consistency, with data from the secure, battery-buffered CMOS-RAM represents a further safeguard against parameter falsifications triggered by RAM hardware faults.
Combined with the RAM failure rate of approx. 10exp-7/h [4], the special fault mechanism required for parameter falsification and the cyclical update of data from secure storage, the manufacturer has taken sufficient measures to protect against unintentional parameter changes.
((]
Thanks to the generally excellent structuring of programs, their quality, comprehensibility and testability remains largely unaffected by the interpretation of user inputs via the control panel and V24 implemented two-fold - in the monitor and server tasks of NZ12 - and by the formal breaches of the rules of structured programming detailed in sections 5.1.3, 5.2.3 and 5.3.3. Corresponding rectifications are therefore not required.
In summary, the software of the digital wide-range channel DWK250 meets the requirements of the KTA rules for comparable hardware interms of its structural quality, while also complying with the structural specifications of the draft standard DIN V VDE/801 when taking the notes in sections 6 and 7 into account. The correct functional implementation of the NZ21 reactor protection functions was verified by means of an analytical, tool-based test procedure independently of relevant implementation documentation.
PB_ DWK250OSoftware_160890
Non-proprietary Version TUV Norddeutschland Code inspection and computer-based static program analyses were used to confirm the decoupling of reactor protection functions from the measurement, control, reporting and display functions implemented in NZ12 and NK21, or to establish information on structural modifications since implemented in order to enable this verification. The DWK 250 functions not intended for reactor protection were tested by means of static program analysis (NK21), code inspection (NZ12) and in the context of tests before being verified on the basis of the above information.
In terms of its measurement tasks in the field of reactor protection, the DWK 250 software is able to meet the relevant requirements in line with the state-of-the-art of science and technology.
This type test was conducted on a non-plant-specific basis. Additional suitability tests may be necessary to establish whether the type-tested software of the digital wide-range channel DWK250 can meet the requirements resulting from individual, plant-specific licensing procedures.
The inspection certificate for the digital wide-range channel DWK250 has the certificate no.
1225068496/01, dated 16/8/1990.
Hamburg, 16/8/1990 (Mainka)
(Mehrgardt)
PB_ DWK250_Software_160890
Non-proprietary Version TUV Norddeutschland Literature
[1] Final report of VdTUV research initiative 210, "nuclear technology' section, March 1988. TOV Norddeutschland
[2]: BMFT research report 'Tools for standardised software safety analysis" (SOSAT), final report, August 1987
[3]: BMFT research report 'Tools for standardised software safety analysis" (SOSAT 2), 2nd technical report, volume 1,10/1989
[4]: Intel Components Quality/Reliability Handbook 1987 PB_ DWK250OSoftware_160890
Non-proprieta ry I TtV RHEINLAND Inspection certificate File reference: T1 7.1 9.3 Certificate no.: T-0101191 Order no.: 979/880057 Type of inspection: Type testing of DWK 250 Project: WOrgassen nuclear power plant Designation of inspected product Digital Wide-Range Channel DWK 250 Type designation Equipment identification:
Ma nufa ctu re risu pp tier: Mannesmann; Hartmann &Braun, Munich plant Associated documents: Technical test report no. 91101101 Requirements: See technical test report no. 91101101 Inspection location: Hamburg and Cologne Inspection date: 1989-1991 Inspectors: Grad. Eng. Mainka, Grad. Eng. Mehrgardt, TOV Norddeutschland Grad. Eng. D~nnart, Grad. Eng. Gall, TUV Rheinland Inspection result: The inspection was passed in accordance with the above test report.
Cologne, 1991-01-15 TOV Rheinland On behalf of inspectors: .
Attachments:
(D~nnart)
114 1-r- 0?(d)
Non-proprietary Version ARCHIVE No. 59 This is a non-proprietary version from which the proprietary 1991-09-12 information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( ))
p Technical test report Test object Digital Wide-Range Channel DWK 250 manufactured by Mannesmann Hartmann & Braun No. 91/01/01 H.-J. Dnnart
- 0. no.: 979/880057 File ref.: T17.19.3 Date: January 1991 Rev. A of 1991-07-10
Non-proprietary Version Table of contents Page:
- 1. Introduction 2
- 2. Description of test object 2
- 3. Test requirements 19 3.1 General information 19 3.2 Theoretical test 19 3.3 Practical test 20 3.4 Global test 21
- 4. Result of theoretical test 21 4.1 Testing of equipment documents 21 4.2 Software test 22 4.3 Reliability data 23 4.4 Critical load analysis 25 4.5 Test program for practical test 25
- 5. Result of practical test 25
- 6. Result of global test 26
- 7. Documentation and modification procedure 26
- 8. Summary 27
- 9. Documents 27 9.1 General documents 27 9.2 Equipment documents 28 9.3 Test documentation 33 Appendix: Test certificate
Non-proprietary Version
- 1. Introduction According to KTA rule 3501 /9.1.1/, newly developed or modified equipment (modules) of the reactor protection system must be subjected to type testing to ensure that the modules correctly perform the relevant tasks and that they and their components meet the specified requirements. As part of the supervisory procedure for the Wurgassen nuclear power plant, TUV Rheinland was therefore commissioned by Mannesmann, Hartmann & Braun to perform this type testing - that is, the testing of the system data for the digital wide-range channel DWK 250.
The hardware and software of the digital wide-range channel DWK 250 are modular constructions made up of components of the nuclear radiation measurement system TK 250.
The channel plug-in modules are combined in a 19" module rack.
The type testing of the DWK 250 was overseen by the nuclear technology department of TOV Rheinland. The software was tested by TOV Norddeutschland.
The microelectronics test centre of TOV Rheinland served as the venue for the global test as well as the theoretical and practical tests of the individual plug-in modules, which were conducted in the form of individual type tests or in a system with other measurement tasks of the measurement channel.
The final technical test report for the type test was created by the authorised inspector (as per § 20 Atomic Energy Act), Grad. Eng. D13nnart.
- 2. Description of test object Below are copies of manufacturer document no.: 5-0106 D22 pages 3 to 17 and no.: 5-0106 A70 page 41
Non-proprietary Version
- 1. Functional specification 1.1 Features The digital wide-range channel is used to measure neutron flux density from the start-up range to approx. 10% nominal reactor output. By combining the earlier start-up and intermediate range channel, space requirements in the electronics cabinet have been reduced to a quarter, while the number of detectors, penetrations and pre-amplifiers is effectively halved. Wiring and testing requirements can also be reduced significantly.
The features of the digital wide-range channel are as follows:
- In-core core neutron flux measurement for start-up and intermediate range with just one detector
- Ten decade measuring range
- Acquisition of detector pulses in the pulse range (start-up range)
- Acquisition of detector AC signal (intermediate range) with lockable auto-range function
- Processing of both signals as linear analogue outputs for the reactor protection system
- Generation of the wide range signal by merging pulse signal and AC signal
- Calibration as neutron flux signal
- Signal smoothing with adjustable attenuation curve
- Calculation of relative signal change rate
- Two freely scalable analogue outputs, linear or logarithmic, for operational purposes, e.g. display or recorder
- Monitoring of up to 16 adjustable limit values
- Remote-controllable test signal generators in all input modules, including pre-amplifier
- Continuous functional monitoring
. Numerically adjustable parameters, lockable and secured against power failure
- Operation and testing possible via external computer No.: 5-0106 D22 Version 2 of 16/1/1991 Page 3 of 17
Non-proprietary Version 1.2 Signal processing In the combined pre-amplifier TKV23, the detector signal is split into the pulse path (start-up range) and the AC path (intermediate range). In the mainframe, the two signals are processed electronically, digitised and numerically combined to form the wide-range signal.
The pulse signal is transferred to a counter via a discriminator with adjustable threshold. The AC signal travels to a pre-amplifier with switchable measuring ranges. The measuring range switchover occurs automatically, provided the relevant release signal is present. The AC signal is then squared (autocorrelation) and transferred to the processor for numeric processing after the A/D conversion.
((
))
The detector voltage and the internal operating voltages are monitored for observance of pre-defined tolerances. The microprocessor and its (program, data, parameter) memories are subjected to constant background monitoring during normal functional sequences.
[))
No.: 5-0106 D22 Version 2 of 16/11991 Page 4 of 17
Non-proprietary Version
- 2. Elements of the measurement assembly 2.1 Detector and pre-amplifier In a fission chamber, individual charge pulses are generated by the neutrons to be measured. In the case of high neutron flux, the charge pulses combine to form a direct current, which is subject to superimposed fluctuation due to the static nature of the pulses.
Since the insulating properties of the detector and connecting cable are limited by the high operating temperature, the detector current is falsified by an (insulation) leakage current. As a result, the actual direct current of the detector cannot be measured directly in the case of low reactor output.
However, according to Campbell's theorem, which is well known in the field of statistics, the root mean square of the superimposed alternating current represents a precise measure of the direct current generated by the neutrons. The required squaring also effectively suppresses the smaller pulses originating from gamma radiation.
((
1]
2.2 Measurement channel structure The hardware and software of the digital wide-range channel DWK 250 are modular constructions made up of components of the nuclear radiation measurement system TK 250.
The channel plug-in modules are combined in a 19" module rack, which should ideally be housed in an electronics cabinet but can also be mounted in wall or table housings.
Refer to appendix A.2 for a view of the measurement channel No.: 5-0106 D22 Version 2 of 16/1/1991 Page 5 of 17
Non-proprietary Version 2.3 Hardware The following plug-in modules are elements of the DWK 250:
lx NH 36.51 ((
- x. NA 33.11 lx NB 22.11 lx NI 21.11 lx NZ 21.11 lx NZ 12.11 1 to 2x NB 21.11 2x NT 51.11 Alternatively NT 41.11 1x NN 53.11 Alternatively NN 43.11 11 Depending on the application, the following modules can also be installed additionally:
lx NE31.11 ((
nx NT 51.11 nx NT 41.11 lx TKKR31.11 I to 2x NA 04/06 lx NK21.11 lx NS 01.12 Required pre-amplifier:
lx TKV23 Suitable detector:
lx WSK61 11 No.: 5-0106 D22 Version 2 of 16/1/1991 Page 6 of 17
Non-proprietary Version 2.4 Software The functional sequence of the wide-range channel DWK 250 is defined by the software, which is stored in EPROMs (i.e. non-modifiable) on three processor modules:
[I
))
Comparison:
((
11 Software areas relevant to reactor protection are combined on the module NZ 21. The hardware and software of the modules NZ 21 and NZ 12 is connected solely via the internal serial bus (S-Bus) and no reciprocal access to the program and data memory takes place. In the case of a failure of the main processor NZ 12, the module NZ 21 remains fully functional.
These measures reduce the number of hardware and software modules involved in the reactor protection path, thus increasing reliability and enabling the use of varying inspection severities for the qualification of software packages on the modules NZ 21 and NZ 12.
No.: 5-0106 D22 Version 2 of 16/1/1991 Page 7 of 17
Non-proprietary Version
- 3. Operating principle 3.1 Multi-processor system Like all devices of the digital measurement system TK 250, the digital AC channel DWK 250 also features multiple central modules as processing units, each of which is equipped with its own type 8031 processor.
A serial bus is used for the message exchange between the processors of a device's central modules.
3.2 Software structure The software of the digital measurement system TK 250 features a strict modular structure, whereby the system software is largely identical for all applications.
The majority of the software is written in the high-level programming language PL/M, which facilitates program testing and maintenance. Only individual time-critical parts are written in assembler.
A simple real-time operating system with minimal storage requirements supports the multitask structure of the measurement system TK 250:
- The individual functions (e.g. measurement, operation via the control unit, operation from the external computer) can run simultaneously without interfering with one another.
- The multitask concept facilitates the modularisation of the software as well as the meeting of time conditions.
No.: 5-0106 D22 Version 2 of 16/1/1991 Page 8 of 17
Non-proprietary Version 3.3 Operation The digital wide-range channel DWK 250 can be operated manually on the system front panel or by means of an external computer via the serial interface.
The current measurement remains unaffected by all operations. The measurement and operating procedures run in parallel and independently of one.another.
The operable functions are as follows:
starotrnn & Urema TI2J5-
- Measured value display IF77* CiTTT7 I
- Querying of messages Floss 'Cs
- Parameter queries and settings
- Test procedures All manual operations are performed by meansof LIlf1 I 8: function keys; measured values and dialogue messages appear on a front panel LCD .
comprising 2 lines, each displaying up to 16 alphanumeric characters. The selected measurements and parameters are displayed. with their name, numeric value and dimension.
The parameters of the numeric signal processing are digitally adjustable (with the exception of the reactor protection path) and are protected against both unauthorised changes and power failure.
The two analogue outputs for displays or external monitoring can be parameterised by the user with linear or logarithmic characteristics and with specific range limits for all existing
.measured values. Isolation amplifiers can be connected as a means of potential isolation.
The maximum of 16 limit values can be parameterised as upper or lower limits with user-defined thresholds and hysteresis for all existing measured values; using an OR operator, multiple limit values can be combined on a single binary output, while faults, test messages and limit value Violations are reported with the aid of the installed binary signal modules via dry relay contacts.
The pre-amiplifier and the pulse or AC input modules of the mainframe! are equipped with test levels that can be activated from the operating menu using the keypad.
No.: 5-0106 D22 Version 2 of 161/1991 Page 9 of 17
Non-proprietary Version 3.4 Test features The function of the digital wide-range channel can be tested using pre-installed test signal generators in the pre-amplifier TKV 23 and in the input modules NI 21 and NA 33. Binary and analogue output signals can be simulated to inspect the peripheral equipment connected to the outputs. Important hardware components (e.g. microprocessors, memory, supply voltages), program sequences and internal data transfers are constantly monitored during normal operation.
- 4. System integration With its automatic measuring range switchover and combination of the start-up and intermediate range, the digital wide-range channel enables continuous neutron flux monitoring and calculation of the neutron flux change rate over a range of approx. ten decades without the need for external user intervention.
As well as providing the reactor operator with this essential visual information, the channel also supplies trip signals for the reactor protection system in the form of a separate signal path optimised for simplicity and reliability.
The autorange function with its time-out feature and external start-up lock represents a fully-fledged replacement for the earlier manual range switch function and effectively relieves the reactor operator from unnecessary activities.
However, the digital wide-range channel also permits extensive adaptation to existing display and operating concepts:
- With the expansion amplifier on module NA 33, the previous AD signal (0.1 to 5E5 ips) can be supplied from the wide-range signal or directly via the parameter settings.
- The UD signal C"sawtooth") and the measuring range setting (via TKKR 31) are also available.
- The manual measuring range switchover can be recreated with the aid of the measuring range start-up lock (= triggering of measuring switchover by keypress).
The automatic shutdown remains intact.
No.: 5-0106 D22 Version 2 of 16/1/1991 Page 10 of 17
Non-proprietary Version
- 5. Safety requirements and qualification The digital wide-range channel DWK 250 is constructed according to the generally applicable, legal safety requirements. With regard to electrical safety, the following standard applies in particular:
- DIN 57411 (VDE 0411) Part I (10.73) Protective measures for electronic measuring instruments The device is developed, manufactured and tested in strict compliance with the following regulations:
- KTA 3501 Reactor protection system...
- KTA 3502 Accident measuring systems
- KTA 3505 Type testing ...
- KTA 3507 Factory tests ...
- KTA 1401 General requirements regarding quality assurance
- Quality assurance manual, Hartmann & Braun AG, Frankfurt/M.
- Quality assurance manual for Munich H&B plant
- Quality assurance manual for software development, Hartmann & Braun, Munich plant The type test certificates for the individual components are listed in the following table:
Component Kit Inspector Date Certificate no.
Whole channel 5-0106 TUV RhId. 15/1/1991 T-0101/91 Software 5-0106 TOV Nord. 16/8/1990 1225068496/01 NI 21 6-7690 TUV RhId. 8/8/1988 T-0801/88 NH 3X 6-7519 TOV Rhid. 8/8/1988 T-0801/88 NA 33 5-0103 TOV RhId. 7/5/1990 T-0502190 NB 22 5-0102 TUV Rhld. 7/5/1990 T-0502/90 NZ 21 6-7689 TOV RhId. 8/8/1988 T-0801/88 NZ 12 6-7699 TOV RhId. 8/8/1988 T-0801/88 NK21I 6-7687 TOV RhId. 8/8/1988 T-0801/88 NA 04/06 5-0088 NB21 6-7648 TOV RhId. 8/8/1988 T-0801/88 NN 43/53 6-7694 TOV Rhid. 8/8/1988 T-0801/88 NS 01 5-0044 (H&D verific.) 22/8/1989 5-0044 Q01 NT 41/51 6-7697 TUV RhId. 8/8/1988 T-0801/88 TKV 23 5-0009 TOV RhId. 11/11/1987 KVWV-1101/87 No.: 5-0106 D22 Version 2 of 16/1/1991 Page 11 of 17
Non-proprietary Version
- 6. Technical data The following specifications partially represent excerpts and selections of the module data providing essential information on the digital wide-range channel DWK 250.
6.1 Pre-amplifier (TKV 23)
Input resistance Pulse amplification Pulse output AC amplification AC bandwidth Test level 1 and 2 Detector voltage 6.2 Input signals Pulse input (NI 21)
Pulse sequence Discriminator threshold Input resistance Test level 1))
AC input (NA 33)
Input voltage Uhe Output voltage U1 U2 Test level Dry logic inputs (NB 21) 24 V logic:
((
H level Lilevel Input resistance Potential isolation ]
Active contact scanning (Ve connected to Ee in each case):
Scanning voltage R Potential isolation No.: 5-0106 D22 Version 2 of 16/1/1991 Page 12 of 17
Non-proprietary Version 6.3 Signal processing Signal filtering Filter type 1st order low-pass with controlled time constant Min./max. time constant Adjustable benchmark values Floating time constant as function of input signal between benchmarks Response times Reactor protection signals Wide-range signals Signal processing errors Num. signal processing, incl. counting and [
averaging errors Discr. dead time error for td=40ns at 100,000 ips (only for static pulse sequences!)
Analogue inputs NZ 21 Analogue outputs NZ 21 Lin. count rate output NZ 21 Input/output isolation amp. NT..
Digital display NZ 12 Errors fl, f2 and f35 refer to the relevant current measurement, while errors f31, f32, f33 and f34 relate to the end value of the electrical signal, e.g. 10 V or 20 mA.
The discriminator dead time (and thus error f2) can be compensated numerically in conjunction with the detector dead time.
Error outputs f1 to f35 represent absolute values (+ is possible!).
6.4 Output signals Analogue signals (dry via NT 41/51.11)
Output current Burden Potential isolation Contact outputs Contact type Switching voltage Switching current Switching power Potential isolation (test volt.)
No.: 5-0106 D22 Version 2 of 16/1/1991 Page 13 of 17
Non-proprietary Version 6.5 Digital specifications and interfaces Microprocessor Type ((
Clock frequency Program memory Parameter memory Internal serial bus (S-Bus)
Type Speed External asynchronous data interfaces RS-232C interface (V.24) or line current interface (TTY) or RS-485 interface 6.6 Auxiliary power DC voltage supply (NN 43)
Rated voltage ((
Tolerance range (modules)
Overvoltage Power failure Ripple (peak-peak)
Potential isolation (24 V intern.)
AC voltage supply (NN 53)
Rated voltage and tolerance Frequency Power consumption Transient overvoltage Power failure Potential isolation (220 V intern.)
Internal supply voltages Logic supply Analogue supply Detector voltage (NH 36) ]
No.: 5-0106 D22 Version 2 of 16/1/1991 Page 14 of 17
Non-proprietary Version 6.7 Environmental conditions Climatic stress Operating temperature range Module rack (open)
Wall and table housing Storage temperature range Relative air humidity Mechanical stress Vibration resistance (transport)
Short-term load Impact load 6.8 Mechanical structure 19" construction system according to DIN 41494 (TE = 5.08 mm)
Plug-in cards and blocks (Front panel) height ((
(Front panel) width Circuit boards Multiple connectors Front panel colour Module rack Width Mounting surface Height ))
Wiring No.: 5-0106 D22 Version 2 of 16/1/1991 Page 15 of 17
Non-proprietary Version Appendix A.1 Block diagram
((
No.: 5-0106 D22 Version 2 of 16/1/1991 Page 16 of 17
Non-proprietary Version A.2 Equipment - view A.3 Ust of technical documents Digital wide-range channel DWK 250 Doc. no.:
User manual DWK 250 5-0106 A70 Quick guides DWK 250 5-0106 A50 Data sheet: parameters DWK 250 5-0106 D21 Computer interface DWK 250 5-0106 B93 General documents forTK 250 General protection and safety measures 5-0125 A01 Standard data TK 250 25 438-ms9 Techn. information on modules Various No.: 5-0106 D22 Version 2 of 161/1991 Page 17 of 17
Non-proprietary Version Appendix A.2 Signal flow
((
1]
Non-proprietary Version
- 3. Test requirements 3.1 General information According to KTA rule 3501 /9.1.11, newly developed or modified equipment of the reactor protection system must be subjected to type testing. This is to ensure that the modules meet the specified requirements. The test conditions for the theoretical and practical tests were defined in accordance with KTA rule 3505 /9.1.2/. The qualification of the software was performed on the basis of DIN V VDE 0801, as per the test report of TOV Norddeutschland
/9.3.3/. Since type testing is only performed on a limited number of the devices to be tested, the type test initially serves to establish the suitability of the device type. To verify the quality of production runs of type-tested equipment, as stipulated by KTA 3501 /9.1.1/, the manufacturer is required to perform factory spot checks on a representative sample under the relevant operating and critical load conditions. The necessary factory tests are conducted by the manufacturer independently and in compliance with applicable rules and regulations.
The quality assurance system of the manufacturer H&B, as the entirety of all organisational and technical measures implemented for quality assurance purposes, was not specifically examined with regard to the product DWK 250. Generally positive assessments of the quality assurance measures in the manufacturer's Munich plant can be found in the technical test report no. 88/08/01 /9.3.1/.
3.2 Theoretical test The test requirements for the theoretical test correspond to KTA 3505 /9.1.2/. The following theoretical tests are to be performed:
Non-proprietary Version
- Inspection of submitted documents for completeness and correctness
- Failure rate determination for hardware components
- Critical load analysis for hardware components
- Software analysis comprising:
- Specification test according to checklists
- Recording of hardware-based boundary conditions
- Computer-based control and data flow analysis
- Verification of program parts with
- decoupling confirmation
- Black box and white box test
- Global test
- Creation of test program for practical testing of modules NA 33 and NB 22 in accordance with KTA 3505 /9.1.2/
- Creation of test program for global test of DWK 250 including pre-amplifier TKV 23 3.3 Practical test The requirements for the practical testing of modules NA 33 and NB 22 are specified in the test program report no. 945/ K 72204 /89 /9.1.4/ and summarised in the technical test report no. 90/05/02 /9.3.2/.
The test requirements for all other modules flagged with
- in section 2.3 of the manufacturer document (page 6 of 17) are specified in the test program report no. 945/ K 71106/87 /9.1.3/
and summarised in the technical test report no. 88/08/01 /9.3.1/. All test requirements were created in accordance with KTA 3505/9.1.2/.
Non-proprietary Version 3.4 Global test The requirements are specified in the test program for the global test of DWK 250 /9.1.5/.
The aim of the global test is to verify the measurement channel function on the basis of the manufacturer documents "Specification/technical information" /9.2.1/ and "User manual"
/9.2.2/
- 4. Result of theoretical test 4.1 Testing of equipment documents TOV Rheinland is in possession of all equipment documentation for the digital wide-range channel DWK 250.
This comprises the descriptive documents,
- Specification/technical information /9.2.1/
- User manual /9.2.2/
- Quick guide /9.2.3/
the documents relating to the plug-in modules,
- Kit tables of contents /9.2.4/to /9.2.13/
- Technical information documents, data sheets
- Circuit diagrams
- Item lists
- Layout diagrams
- Circuit boards as well as the kit table of contents /9.2.21/for the digital wide-range channel DWK 250.
In terms of their completeness and correctness, the above equipment documents meet the requirements of KTA 3505 /9.1.2/. Specific results can be found in the test documentation, i.e. test reports /9.3.1/to /9.3.4/.
Non-proprietary Version Exception: The kit tables of contents * /9.2.11/ and * /9.2.13/ do not represent the qualification status as per the technical test report /9.3.1/. Following the type testing of the modules NT41, isolation amplifier, and NN43.11, power supply, a range of kit modifications were made. TUV Rheinland e.V. was informed of these changes in a letter dated 1/3/1991
/9.2.15/. The change descriptions are contained in /9.2.16/ and /9.2.17/. A re-examination was successfully completed with tailored test programs. The test results can be found in documents /9.2.17/to /9.2.20/.
The key switch plug-in module **/9.2.12/ was not subjected to type testing.
4.2 Software test The type testing proved that the software of all three modules (NZ21, NZ12 and NK21) is of high quality, both with regard to the logical, specification-based structuring of functions and in terms of formal implementation criteria. Although no CASE tool was used in its creation, the software design and program source documentation is of a good standard, in some cases even exemplary.
A summary of the functions and technical data verified during testing of the DWK 250 is provided in appendix 7 of the test report /9.3.3/.
To reliably decouple the reactor protection functions implemented on NZ21 from those on the main processor, as specified by the manufacturer, additional hardware and software measures were implemented which:
Non-proprietary Version
- Enable detection of the falsification of pulse discriminator thresholds on NZ12 during transfer to NZ21
- Allow setting of the binary outputs on NZ12 at 50 ms intervals during interrupt lockout only in a unique computer state By masking the test signal output with the test release and forcing simultaneous triggering of the test message, the manufacturer has implemented further measures to ensure separation of the NZ1 2 functions from the NZ21 reactor protection functions.
In terms of its measurement tasks in the field of reactor protection, the DWK 250 software is able to meet the relevant requirements in line with the state-of-the-art of science and technology.
Specific results can be found in the test report of TUV Norddeutschland /9.3.3/.
4.3 Reliability data The failure rates of the plug-in modules and combined pre-amplifier TKV 23 were determined in the completed type tests as per the reports /9.3.1/, /9.3.2/, /9.3.5/ and /9.3.6/.
Non-proprietary Version The total failure rates are summarised below:
Type Designation Total failure rate at 40°C NZ11/NZ12 Main processor ((
- Control unit NZ 21 Input/output processor NK21 Serial interface NA 33 AC input NB 22 Decoder/level converter NE 31 Pulse decoupling NI 21 Pulse discriminator NT41/51 Isolation amplifier
- Circuit board
- Function amplifier
- Power supply NB21 Binary input/output TKV 23 Combined pre-amplifier :i Notes:
- 1. The module NH3X - of identical construction to TKKH33, 34 - is qualified by the RWTUV test certificate "Suitability test certificate IV.3.1-3/83 dated 6/6/1983.
- 2. The total failure rate of the module NN43 was not assessed. As part of the practical tests detailed in the report /9.3.1/, special test steps were executed, which proved the reliability of the power supplies.
Non-proprietary Version 4.4 Critical load analysis The critical load analysis created by TUV Rheinland confirms that the various components and their electrical connections are not stressed beyond the permitted thresholds, either statically or dynamically, on the individual plug-in modules. Specific results can be found in the test reports contained in the test documents /9.3.1/ and /9.3.2/.
4.6 Test program for practical test The test programs developed by TOV Rheinland for the practical testing of the various plug-in modules (individually and/or in the system) /9.1.3/, /9.1.4/ and the test program for the global test /9.1.5/ describe the type, sequence and scope of the tests as well as the required equipment.
The test instructions were created by the authorised inspector in coordination with manufacturer Hartmann & Braun AG in accordance with KTA 3505. The manufacturers comments on the test programs were taken into account in the practical tests.
- 5. Result of practical test The results of the practical testing of modules NA 33 and NB 22 are documented in the technical test report no. 90/05/02 /9.3.2/. The test results for all other modules flagged with
- in section 2.3 of the manufacturer document (page 6 of 17) are documented in the technical test report no. 88108/01 /9.3.1/.
The tests were passed in accordance with KTA 3505/9.1.2/.
Non-proprietary Version
- 6. Result of global test The global test of the DWK 250 and combined pre-amplifier TKV 23 was completed successfully. Specific results can be found in the test documentation /9.3.4/.
- 7. Documentation and modification procedure The documentation for the completed type testing comprises the equipment documents as per section 9.2 and the test documentation as per section 9.3, which in turn consists of the individual documents for the theoretical and practical tests.
This combined documentation is archived both at TOV Rheinland, with the file reference T1 7.19.3, and at Hartmann & Braun's Munich plant.
TOV Rheinland must be notified of future modifications to the digital wide-range channel DWK 250 (hardware and software changes) and revisions to the documentation, otherwise the results of the type test will be rendered invalid.
An addendum to this test report is required in the case of major changes having a significant impact on the results of the type test.
In the case of formal modifications, the revised equipment documents /9.2.1/ to /9.2.11/,
/9.2.13/ and /9.2.14/ must be submitted in duplicate to the authorised inspector, who then checks and officially approves them before returning a single copy to the manufacturer for confirmation purposes.
Non-proprietary Version
- 8. Summary With the presentation of this test report and the test certificate contained in the appendix, the type test is deemed passed in accordance with the test requirements detailed in section 3.
The objective of verifying the reliability of the reactor protection component on the basis of theoretical and practical tests has been met. The necessary factory tests are to be conducted by the manufacturer independently and in compliance with applicable rules (e.g. KTA 1401 and KTA 3507) and regulations.
- 9. Documents 9.1 General documents
/9.1.1/ KTA 3501 KTA safety rule Reactor protection system and surveillance equipment of the safety system Version: 6/85
/9.1.2/ KTA 3505 KTA safety rule Type test of transmitters and transducers of the reactor protection system Version: February 1986
Non-proprietary Version
/9.1.3/ TOV Rheinland Test program for practical test according to KTA 3505 Digital pulse channel DPK 250 Report no.: 945/K 71106/87 rev. B Date: 2/12/1987
/9.1.4/ TOV Rheinland Test program for practical test according to KTA 3505 Modules NA 32, NA 33, NI 22, NB 22 of the digital nuclear radiation measuring system TK 250 Report no.: 945/K 72204/89 Date: 4/12/1989
/9.1.5/ TOV Rheinland Test program for global test of DWK 250, digital wide-range channel manufactured by Hartmann & Braun File ref.: T 17.19.3 Date: 17/12/1990 9.2 Equipment documents
/9.2.1/ Hartmann & Braun Specification / technical information Digital wide-range channel DWK 250 No.: 5-0106 D22 Version 2 of 16/01/1991
Non-proprietary Version
/9.2.2/ Hartmann & Braun User manual Digital wide-range channel DWK 250 No.: 5-0106 A70 Version 2 of 16/01/1991
/9.2.3/ Hartmann & Braun Quick guide Digital wide-range channel DWK 250 No.: 5-0106 A50 Version 2 of 15/01/1991
/9.2.4/ Hartmann & Braun Kit table of contents AC input NA 33.11 No.: 5-0103 12 Version 2 of 01/03/1990
/9.2.5/ Hartmann & Braun Kit table of contents Decoder NB 22.11 No.: 5-0102 12 Version 1 of 09/11/1988
/9.2.6/ Hartmann & Braun Kit table of contents Pulse discriminator NI 21.11 No.: 6-7690 12 Version 3 of 13/07/1987
Non-proprietary Version
/9.2.7/ Hartmann & Braun Kit table of contents Analogue processor NZ 21.12 No.: 6 - 7689 12 Version 3 of 09/03/1989
/9.2.8/ Hartmann & Braun Kit table of contents Main processor NZ 12.11 No.: 6 - 7699 12 Version 3 of 25/01/1990
/9.2.9/ Hartmann & Braun Kit table of contents Serial interface NK 21.11 No.: 6 - 7687 12 Version 4 of 04/07/1989
/9.2.10/ Hartmann & Braun Kit table of contents Binary input/output NB 21.11 No.: 6 - 7648 12 Version 3 of 27/05/1987
- /9.2.11/ Hartmann & Braun Kit table of contents Isolation amplifier NT 41 No.: 6 - 7697 12 Version 2 of 05/02/1990
- see page Non-proprietary Version
- /9.2.12/ Hartmann & Braun Kit table of contents Key switch NS 01 No.: 5 - 0044 12 Version 4 of 10/07/1989
- /9.2.13/ Hartmann & Braun Kit table of contents Power supply NN 43 No.: 6 - 7694 12 Version 4 of 09/01/1990
/9.2.14/ Hartmann & Braun Kit table of contents High-voltage unit NH 36.51 No.: 5 - 0140 12 Version 2 of 24/01/1990
/9.2.15/ Hartmann & Braun Letter to TUV Rheinland e.V.
Supplementary type tests of NT41 and NN43 for DWK 250 Dated 01/03/1991
/9.2.16/ Hartmann & Braun Change description for NT41/51 Dated 25/02/1991 NT-ANDRG.doc 3 pages
- see page ** see page Non-proprietary Version
/9.2.17/ Hartmann & Braun Change description for NN43.11 Dated 25/02/1991 NN-ANDRG.doc 3 pages
/9.2.18/ Hartmann & Braun Letter to TOV Rheinland e.V.
Supplementary type tests of NT41 and NN43 Dated 24/05/1991
/9.2.19/ Hartmann & Braun Supplementary type test of NT41.11 6-7697 Q02 3 pages Dated 15/05/1991
/9.2.20/ Hartmann & Braun Supplementary type test of NN43.1 1 6-7694 Q02 3 pages Dated 23105/1991
/9.2.21/ Hartmann & Braun Kit table of contents 5-0106 12 1 page Dated 06/12/1990 Version 2
Non-proprietary Version 9.3 Test documentation
/9.3.1/ TUV Rheinland Technical test report Test object: Pulse channel DPK 250 manufactured by Mannesmann Hartmann & Braun No. 88/08/01
/9.3.2/ TUV Rheinland Technical test report Test object: Modules NA 33, NB 22 manufactured by Mannesmann Hartmann & Braun No. 90/05/02
/9.3.3/ TUV Norddeutschland Technical test report for digital wide-range channel DWK 250 Software developed by Hartmann & Braun AG, Munich Hamburg, 16/08/1990 PB-DWK 250-Software-i 60890
/9.3.4/ TOV Rheinland Documentation for global test of digital wide-range channel DWK 250 manufactured by Hartmann & Braun Report no.: 91/02/02 Date: 05/02/1991
Non-proprietary Version
/9.3.5/ TOV Rheinland Failure rate calculation for modules of pulse channel DPK 250 manufactured by Mannesmann Hartmann & Braun No.: 90/12/01 Date: August 1988
/9.3.6/ TOV Rheinland Technical test report Test object:
Combined pre-amplifier TKV 23.11 manufactured by Mannesmann Hartmann & Braun No. 87/11/01
A4I 047(e)
-o Non-proprietary Version ARCHIVE 59 This is a non-proprietary version from which the proprietary 12/9/1991 information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( ))
Test program for global test of DWK 250, Digital wide-range channel manufactured by Hartmann & Braun File ref.: T17.19.3 Date: 17/1 2/1990
Non-proprietary Version A
TOV Rheinland Nuclear technology department 1 Test program for global test of DWK 250, Digital wide-range channel Manufactured by Hartmann & Braun File ref.: T17.19.3 Date: 17112/1990 Creators of test program:
Grad. Eng. Dannart Grad. Eng. Gall General information: The test program was created in coordination with the manufacturer, Hartmann & Braun, Munich plant, and TUV Norddeutschland e.V., Hamburg Test objective: Verification of the document "Specification / technical information" for the DWK 250 /l/
Reason for testing: The hardware and software of the digital wide-range channel DWK 250 are modular constructions made up of components of the nuclear radiation measurement system TK 250. The channel plug-in modules are combined in a 19" module rack. The plug-in modules were tested individually in different type tests /2/, 151 or as part of a system with other measurement tasks of the measurement channel /3/. The DWK 250 software was also qualified separately in a type test /4/.
Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.v. Telephone: +49 (0)2211806-to TOV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)221/806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Telegram: Technlwa K6ln
Non-proprietary Version Nuclear technology department TOV Rheinland A global test of the measurement channel DWK 250 to verify its function and technical data in accordance with the %specification/technical information" A1/
has yet to be completed.
Test steps: The test steps listed from section 4. represent a targeted selection of test steps from the KTA rules /6/ and /7/ as a means of achieving the test objective.
- 1. Documents
/11 Hartmann & Braun Specification / Technical information Digital wide-range channel DWK 250 No.: 5-0106 D22 version 1 of 12/4/1990
/2/ TOV Rheinland Type test of combined pre-amplifier TKV 23.11 Technical test report no.: 87/11/01
/3/ TUV Rheinland Type test of pulse channel DPK 250 Technical test report no.: 88/08/01 141 TUV Norddeutschland Software test of DWK 250 Technical test report no.:
PB-DWK250-Software-310590 Please direct all correspondence Core working times't.m
- 30 p; I Tci rUb-achungsverain Rheinland 8.V. Telephone: +49 (0)2210806-to TUV Rheinland, specifying the Mon-Thu: 9 am _ 3.30 pm HedOfce 0 organisational unit and employee, Fri: 9 am -12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne I Telex: 8873659 tuv d Telearam: Techntiwa Kbin
Non-proprietary Version Ae Nuclear technology department TOV Rheinland
/5/ TUV Rheinland Type test (hardware) of modules NA 33 and NB 22 Technical test report no. 90/05/02
/6/ KTA rule KTA 3503/11/86 Type test of electrical modules of the reactor protection system
/71 KTA rule KTA 3505/11/84 Type test of transmitters and transducers of the reactor protection system
/8/ Hartmann & Braun User manual DWK 250 No.: 5-0106 A70 Version 1 of: 12/4/1990
/9/ Wurgassen nuclear power plant (KVWV)
L 2a electronics test, neutron flux in source range Channel 1-3 Revision 16 of 27/4/1989
/10/ Worgassen nuclear power plant (KWW)
L 3a neutron flux intermediate range, channel 1-3 and WD4 Testing of electronics Revision 14 of 27/4/1989 Please to TTy direct all correspondence Rheinland, specifying the Core working Mon-Thu: 9amtimes:
- 3.30 pm Technischer Head Office uberwachungsverein Rheinland e.V. Telephone: +49 (0)221/80&-
0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1764 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Telegram: Techniwa Kiln
Non-proprietary Version Nuclear technology department TOV Rheinland
- 2. Test objects 2.1 Execution The global test conducted as part of the type testing of the DWK 250 must be performed on a factory-tested DWK 250 channel (including pre-amplifier TKV 23).
The assembly of the DWK 250 channel (number and type of plug-in modules in the 19" rack) must be documented.
The modules must meet the document status of the relevant type test in accordance with /2/ to /5/.
The software must comply with the software type test status in accordance with /4/.
2.2 Parameter settings for practical test The following basic parameter settings are made for the practical test, unless other settings are required for individual test steps:
Parameter list:
Discr. threshold:.
Dead time:
Saturation correction:
AC scaling:
Neutron flux calibration:
Overlap start:
Overlap end:
Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.v. Telephone: +49 (0)221/806-to TOV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Offica 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne I Telex: 8873659 tuv d Teleoram: Techntiwa Kdln
Non-proprietary Version A
Nuclear technology department TOV Rheinland Time constant control:
Count rate low:
Time constant (count rate low)
Count rate high Time constant (count rate high)
Time constant (dev.)
Voltage monitoring:
High voltage full-scale value:
High voltage lower threshold:
High voltage upper threshold:
Op. voltage 1 lower threshold:
Op. voltage 1 upper threshold:
Discr. voltage lower threshold:
Discr. voltage upper threshold: ))
The parameter settings are practice-oriented and represent the same settings used in the Wurgassen nuclear power plant.
- 3. Test structure 3.1 Test equipment employed (The list of test equipment will be finalised at the start of the tests)
Please direct all correspondence Core working times:,0p Technischer Uberwachungsverein Rheinland e.V. Telephone: +49 (0)221/806-to TUV Rheinland, specifying the Mon-Thu: am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1764 if applicable Postal address: PO Box 101750 D-5000 Cologne I Telex: 8873659 tuv d Telearam: Techntiwa KdIn
Non-proprietary Version A
TOV Rheinland Nuclear technology department 3.2 General description of test structure and measurements The general test structure comprises a computer-based measurement system. The following parameters are adjustable and are measured at the inputs and outputs of the DWK 250:
Setting Measurement Auxiliary power: Voltage Ub Voltage Ub Current lb High voltage Uh Inputs: Pulse rate (imp path) Pulses Voltage Uhe (AC path) Voltage Uhe Voltage U1 (correlator output NA33)
Outputs: Burden Rb Current I (AC signal)
Burden Rb Current I (Wide-range signal)
Burden Rb Current I (period)
Voltage U (lin. count rate)
Voltage U (meas. range control)
LV contacts (NB21)
Please direct all correspondence Core working times: Technischer Uberwechungsverein Rheinland e.V. Telephone: +49 (0)221/806-to TOV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 6000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne I Telex: 8873659 tuv d Telegram: Techn*lwa Ktln
Non-proprietary Version Nuclear technology department TOy Rheinland The storage oscilloscope connected to the computer system allows the creation of plotter graphs for parameters variable over time (step response, residual ripple).
The test structure is displayed in appendix 1.
Testing of the binary module, discriminator threshold, overlap thresholds, pulse limits and electromagnetic interference is partially conducted using additional equipment to the general test structure. Descriptions of these test setups are provided in the explanations of the individual test steps.
3.3 Explanation of characteristic curve to be recorded According to test instructions /9/ and /10/, desired and interfering signals (noise) are measured and captured at the Worgassen nuclear power plant (KWW) for the wide-range detectors WSK 61 between the combined pre-amplifier and the measurement channel. Reproducible pulses (forms), pulse rates and AC signals are to be specified on the basis of these measurement results (pulse form, amplitude, pulse rate).
Please direct all correspondence Core working times: Technischer Uberwachungsverain Rheinland e.V. Telephone: +49 (0)221/806-to TOV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Telegram: Technilwa K61n
Non-proprietary Version A
TOV Rheinland Nuclear technology department 3.4 Test protocol For each test step a test protocol with corresponding attachments shall be created. An example test protocol is provided in appendix 1.
- 4. Visual inspection 4.1 Visual inspection of assembled 19" module rack The purpose of the visual inspection is to check for correct installation and to check whether the labelling of the equipment is in line with the relevant documents. Prior to equipment startup, the visual check is performed to ensure absence of any function-impairing flaws.
4.2 Identity verification as per 5.1 in 161 4.2.1 Status of the module configuration TKV 23.11 Pre-amplifier NH 36.51 High-voltage unit NA 33.11 AC input NB 22.11 Level converter and decoder NI 21.11 Pulse discriminator NZ21.11 Input/output processor NZ 12.11 Main processor with control unit NB 21.11 Binary input/output NT 41./51.11 Isolation amplifier 0 to 20 mA NK 21.11 Serial interface NN 43./53.11 Power supply unit 1
Please direct all correspondence Core working times: Technischer Ube.wachungsverein Rheinland e.V. Telehone: +49 (0)221/806-to TUV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stesn 5000 Cologne 91 (Poll) Fax: +49 (0)22118086 174 if applicable Postal address: PO Box 1017 0 D-5000 Cologne F Telex: 8873659 tuv d Telegram: Techntwa K61n
Non-proprietary Version A
Nuclear technology department - 9 - TO Rheinand 4.2.2 Status of the software
- NZ 12 Main processor, software version:
- NZ 21 I/O processor, software version:
- NK 21 Serial interface, software version:
4.2.3 Test criteria The design state of the modules must be documented. A comparison must then be made with the design states that are specified in the test reports /2/to /5/.
If deltas exist, these must be listed and evaluated. If relevant changes are identified, these must be subjected to a detailed additional test (theoretical/practical).
- 5. Functional tests 5.1 Functional tests under nominal conditions 5.1.1 Voltage supply, internal interfaces Current draw of whole channel Js at Us = 18 V/24 V/32 V Internal voltages +/-15 V and 5 V at Us = 18 V/24 V/32 V Current consumption at internal voltages +5 V and +/-15 V Internal logic level of interfaces NZ21 -NB22 (-NA33, -TKV23)
Please direct all correspondence C re working times: Tech ischer Uberwachungsverein Rheinland e.V. Telephone: +49 (0)221/80&
to TUV Rheinland, specifying the Man-Thu: 9 am - 3.30)pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Telegram: Techntlwa K61n
Non-proprietary Version Nuclear technology department TO Rheinland 5.1.2 Characteristics, step responses 5.1.2.1 Pulse path Input signal on TKV23: Negative rectangular current pulses Frequency 1 Hz to 2.5 x 10 Hz in octave or decade levels, pulse amplitude 1 pA. Pulse duration 1.0 ps (approx. KWW-specific value) (over 20 kQ from 20 mV into 50 Q)
To be measures and recorded:
- Pulse form at input N121
- Display of "raw pulse number" and "neutron flux"
- Analogue display of "log. neutr. flux"
- Signals for "lin. count rate"
- Step responses (for frequency doubling) 5.1.2.2 AC path Input signal on TKV23:
Sinusoidal AC current Je (over 20 kQ from Ue into 50 0)
See appendix 2 for input and output signals.
(The results of the individual type tests were used to calculate the expected values for the intermediate and output signals.)
5.1.3 Overlap behaviour and signal processing Input pulses as specified under (5.1.2.1.), 50 kHz (overlap start!); to examine the overlap behaviour, the pulse duration is initially raised from 1.0 ps to approx. 10 ps (duty cycle 1:1) through continuous doubling, after which the pulse amplitude is increased to approx. 8 pA/l 60 mV by the same method (rectangle-peak-peak, corresponding to approx. 4 pA effective).
The signals on the display must be monitored.
Please direct all correspondean Core working times: Technischer Uberwachungsverein Rhemnand e.v. Telephone: +49 (0)221/806-to TUV Rheinland, specifying the Mon-Thu: 9am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 0-5000 Cologne I Telex: 8873659 tuv d Telecram: Technlwa K6ln
Non-proprietary Version Nuclear technology department TOV Rheinland 5.1.4 Testing of general functions relevant to safety 5.1.4.1 Reactor protection functions AC path limit values:
- Testing of limit value signal formation through application of an AC signal and blocking of the measuring range switchover for any measuring range.
Recording: Limit value signals GWO, GW1, GW2 via AC input. Logging of measuring range (range switch signals).
Measuring range switchover:
- Testing of measuring range switchover through application of 2 ramps (up/down) to TKV23. Ramp-up/-down =< measuring range dynamics/up-down lockout time, so that system follows the ramp.
Recording: Correlator signal on AC input and measuring range switch signals in case of permitted measuring range switchover.
- Testing of effectiveness of up/down lock for limit value formation through application of 2 ramps (up/down) to TKV23. Ramp-up/-down => measuring range dynamics/up-down lockout time.
Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.V. Telephone: +49 (0)221/806-to TUV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Telegram: Techniwa Kdln
Non-proprietary Version TO ARheinland Nuclear technology department - 12 -
5.1.4.2 Functions Testing of time constant control
- The time constants for the following settings must be determined:
Setting "A'l "B" Count rate low 10 ips 103 ips Time constant, count rate low 10 s 10 s Count rate high 100 ips 104 ips Time constant, count rate high 1s 1s The wide-range signal [ips] must be varied within the range 1 - 100 ips for "A" and in the range 100-10 ipsfor"B".
Other parameters:
Checking of the parameters: dead time, AC scaling, saturation correction, overlap start, overlap end, time constant (deviation). Constant input values.
Recording: Neutron flux, double filtered neutron flux, RELFAG (flux change rate) based on the checked parameters.
Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.V. Telephone: +49 (0)221/806-to TUV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)221/806 1764 if applicable Postal address: PO Box 101750 D-5000 Cologne I Telex: 8873659 tuv d Telearam: Technl~wa K6ln
Non-proprietary Version Nuclear technology department TIy Rheinland 5.1.5 Testing of system features relevant to software 5.1.5.1 Quality of signals on the system bus (S-Bus)
Criteria:
- Overshoot
- Slew rate
- Transfer speed acc. to techn. inform. 375 KBaud = 2.66 ps per character 5.1.5.2 Temporal utilisation of operating system NZI2 with typical system loads
- Evaluation of system loads on analysed program; checking of task waiting and run times 5.1.6. Determination of effect of system error states; testing through short-circuit, termination on:
_ Pulse input NZ21
- AC input NZ21 5.1.7 Internal test levels The (output) signals generated by the internal test levels must be logged.
5.2 Function tests at max. temperature (= 70°C) and minimal supply voltage (U = 18 V)
The characteristics determined in 5.1.2 are re-recorded at max. permitted ambient temperature and min. permitted auxiliary power I/l. The measured results must match those from 5.1.2, taking the permitted tolerances into account.
Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.V. Telephone: +49 (0)221/806-to TOV Rheinland, specifying the Mon-Thu:
' am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1764 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Teleoram: Technuwa Kdln
Non-proprietary Version A
Nuclear technology department TOV Rheinland 5.3 Electromagnetic interference 5.3.1 High-frequency interference (radio unit) 5.3.2 Electromagnetic interference according to DIN VDE 0843 part 4 (draft from Sept. 87) (burst generator and coupling section) 5.3.3 Resistance to electrostatic discharge DIN VDE 843 part 2 (ESD generator)
- 6. Vibration/shock test As per KTA 3503 /6/, 5.6 The test is only performed if the 19" plug-in module with DWK 250 assembly differs from the tested version DPK 250 Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.V. Telephone: +49 (0)221/806-to TOV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Teleararn: Technlwa K61n
Non-proprietary Version Nuclear technology department TCy Rheinland
- 7. Testing of electrical properties As per KTA 3503/6/, 5.7
- Current draw
- Power loss
- Self-heating
- Behaviour of test object during plug-in procedures
- 8. Dry heat The DWK 250 and pre-amplifier TKV23 are subjected to a final temperature test over t = 100 h.
The ambient temperature must be Tmax = 700C and the DC power supply is set to Umn = 18 V.
The drift behaviour of the output signals
- AC signal
- Period
- Wide-range signal
- AC path (Ua); output TKV 23 must be monitored continuously with application of a 50% input signal.
Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.v. Telephone: +49 (0)221/806-to TUV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 6000 Cologne 91 (Poll) Fax: +49 (0)2211808 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne 1 Telex: 8873659 tuv d Telegram: Techn~wa KdIn
Non-proprietary Version A
TOV Rheinland Nuclear technology department 9. Test program, regularly recurring tests Based on the test results and procedures, the basic test steps for future, regularly recurring tests on the DWK 250 and pre-amplifier TKV23 must be defined while taking the internal test levels into account.
Cologne, 17/12/1990 977-da-schO Authorised inspector as per § 20 AtG (Atomic Energy Act)
Grad. Eng. Dannart Appendix 1: Block diagram Appendix 2: Test specification for test step 5.1.2.2 "AC current path" Please direct all correspondence Core working times: Technischer Uberwachungsverein Rheinland e.V. Telephone: +49 (0)2211806-to TUV Rheinland, specifying the Mon-Thu: 9 am - 3.30 pm Head Office 0 organisational unit and employee, Fri: 9 am - 12 noon Am Grauen Stein 5000 Cologne 91 (Poll) Fax: +49 (0)2211806 1754 if applicable Postal address: PO Box 101750 D-5000 Cologne I Telex: 8873659 tuv d Telearam: Techniwa K61n
Non-proprietary Version
((
1]
Non-proprietary Version 1[
11
/41/IF _/0 Non-proprietary Technischer Uberwachungs-Verein Nord e.V.
Process control and reactor core department Certificate no. 27-97-YQ-AO1 Hamburg, 07.10.1997 Regarding the acceptance and functional testing of the software 040/8557-2608 of the Digital Wide Range Channel DWK 250 in the KO005 variant 2608-Mai/Sk
- 1. Plant KKK
- 2. Test object Neutron flux measurement system Software of the Digital Wide Range Channel DWK 250 in the K0005 variant
- 3. Operator KI(KGmbH
- 4. Manufacturer or supplier Hartmann & Braun (H&B)
- 5. Basis for test Ministry of Finance and Energy of the Federal State of Schleswig-Holstein:
Approval of 29.08.97 to the amendment application 37/97, File ref.: VI 615-416.756.497 (037/97), /K1797/97)
- 6. Test documentation Neutron flux measurement system / use of digital measuring channels Amendment application 37/97, K726-97 Amendment description 3110 490 A K0005 AB, edition 1/26.06.97
- 7. Test scope, execution and type See Appendix 1
- 8. Date and place of test 26.09- 28.09.1997
- 9. Result The correct implementation of the specified program change and the plant-specific configuration was proven in the test on the basis of the amendment description of the manufacturer and the submitted executable machine program code.
Appendices: Appendix 1 Ernst-Ulrich Mainka Expert from the Technischer Uberwachungs-Verein Nord e.V.
Non-proprietary Technischer Oberwachungs-Verein Nord e.V.
Process control and reactor core department Appendix 1 to certificate no. 27-97-YQ-AO1 regarding the acceptance and functional testing of the software of the DWK 250 in the KO005 variant Software code number of the E/A processor: 3110 490 A K0005 Software code number of the main processor: 3110 489 A K0005, Checksum: 75FC The suitability verification was conducted on the basis of the amendment description 3110 490 A K0005 AB, edition 1/26/06.1997 and the binary program files (executable machine code)
- wapro0.thx of 09.06.1997 (E/A processor) - reference program
" waOhOO.05 of 16.07.97 (E/A processor) - changed and configured program
- wmproO.thx of 09.06.1997 (main processor) - reference program
" wmOhOO.05 of 16.07.97 (main processor) -changed and configured program.
The following test steps were executed:
- Verification of the code numbers of the test report and the submitted binary program files
- Verification of the concurrence of the reference programs with the type-tested program code lodged with the tester
" Verification of the program changes performed on the basis of the change description
- Verification of concurrence of these changes with the changes present in the program file waOhOO.05 (safety-related signal path).
- Verification of the configuration data on the basis of the change description
" Verification of the concurrence of documented configuration data with the changes present in the program files.
The tests related to program code were conducted with the aid of 'CATS' tools for the analysis of machine code programs and with the aid of the 'ED' macro editor.
The test confirmed that the program changes made did not impair the safety-related characteristics of the initiation channels proven in the type test and the documented configuration was correctly implemented.
Non-proprietary Nuclear radiation measuring technology HARTMANN & BRAUN TK 250 digital measuring system CHANGE DESCRIPTION: Software name: DWK 250 Software code number: 3110 490 A K0005 (NZ 21) with 3110 489 A K0005 (NZ 12)
Customer / project: KKK Order number: 3457 0009 / FB 128 757 Type of change: software change and project-specific configuration Technical data: (project-specific configuration)
Scaling for AA4: count rate 0 ... S.0eS cps Project-specific configuration parameters Adjusted loading values for standard parameters Qualification:
The software (code) was changed slightly compared with the type-tested software version. The scale end value of the counting rate is now configurable for analogue output #AA4 using EQU instructions.
Change description: NZ 21: 3110 490 A WAPROO.INF NZ 12: 3110489 AWMPROO.INF Origin, reference objects: NZ 21: 3110 350 B NZ 12: 3110 347 B Certification for reference objects: No. 1225068496/01 of the TOV Nord e.V, of 16.08.1990 The accuracy of the software change performed and the accuracy of the changed configuration parameters was proven by the following tests:
- Proofreading of the amended sources by the developer
- Ad hoc test of the changed software by the developer
- Computer based comparison of the sources of original SW and changed SW. Verification of the discrepancy files by the developer.
- Verification of the SW function and the changed configuration parameters by the developer in the presence of the factory expert.
The result of the test is recorded in file printout DWKSWID.TXD and filed under '3110 490 A K0005' in the SW archive.
Hartmann & Braun Fax: 089/58005-169 Landsberger Str. 328 Munich factory Tel.: 089/58005-101 D-80687 Munich Test content: Processed: M~iller/GEK-M 3110 490 A K0005 AB Form. approval: Issued: 1 / 26.06.1997 Page I of I
/q IT-il Non-proprietary Version
' TUV Rheinland I
This Is a non-proprietary version from which the proprietary Gruppe Test information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are Indicated by two opening and two closing brackets as shown here: 1[ ))
Taeiinn ran+ro far microelectronics and process Certificate automation at the ISEB Certificate no. I 945/K 73004/951 Test object Serial Manufacturer interface NK 21 Mannesmann Hartmann & Braun AG Werk MUnchen Landsberger Strale Type Software NK 328 80687 Munich 21 3110342 C Intended application Serial interface for data exchange of TK 250 channels with other computer equipment Test report no. 945/K 73004/95 Customer Mannesmann Hartmann & Braun AG Werk Milnchen Landsberger StraBe Dated 7 March1995 328 80687 Munich Codes and Standards forming KTA 3501, 3505 the basis of testing DIN VVDE 0801 TUV Rheinland - Report no. 945/K 71701/88, Rev. A Test result Passed, as per test report no. 945/K 73004/95 Specific requirements See test report no. 945/K 73004/95 The above-mentioned test report is an integral part of the present certificate.
TUV Rhelnland - Am Grauen Stein - Postfach 10 17 50 - 5000 Cologne - Germany Tel 0221 / 806-26 68 - Fax 0221 1806-17 36
Non-proprietary Version ISEB Institute for Software, Electronics and Railway Technology Accredited in Europe a Accepted around the world TUV Rheinland 07/03/1995 Microelectronics and Process Automation Feedback on the changes to the software for assembly NK21 of the TK 250 Digital Radiation Monitoring System manufactured by Hartmann & Braun Report no.: 945/K 73004/95 Date: 07/03/1995 Report no.: 945/K 73004/95 Page I of 9
Non-proprietary Version ISEB Institute for Software, Electronics and Railway Technology Accredited in Europe
- Accepted around the world TUV Rheinland Feedback on the changes to the 07/03/1995 software for assembly NK21 of the TK 250 Digital Radiation Monitoring System manufactured by Hartmann & Braun 945/K 73004/95 Report no.:
Report date: 0710311995 No. of pages (without appendices): 9 Test object:
Software for assembly NK21, part no.
3110 342 C Manufacturer: See Customer Customer: Mannesmann Hartmann & Braun AG Werk MOnchen Landsberger Stralle 328 80687 Munich Customer order no./date: 151/45126020 dated 2 August 1994 Test institute:
TOV Rheinland Sicherheit und Umweltschutz GmbH Institut fOr Software, Elektronik, Bahntechnik (ISEB)
Postfach 91 09 51 51101 Cologne Am Grauen Stein 51105 Cologne Department: Microelectronics and process automation Customer order no./date:
945/445114 dated 9 August 1994 Quote no./date:
945/12694 dated 15 March 1994 Compiled by:
Dipl.-Ing. Klaus Kemp Test location:
See Test institute Testing period:
January 1995 to March 1995 Test results refer exclusively to test objects.
No extracts from this report may be duplicated without the written consent of the test institute.
Report no.: 945/K 73004/95 Page 2 of 9
Non-proprietary Version ISEB Institute for Software, Electronics and Railway Technology Accredited in Europe
- Accepted around the word Tdv .... in,, nd 07103/1995 Contents Page
- 1. Definition of task 4
- 2. Codes and standards forming the basis of testing 4
- 3. Test item 5 3.1 Documents and program source codes submitted for the test 5 3.2 Equipment used 5 3.3 Test object 6
- 4. Conduct and results of test 6 4.1 Formal test 6 4.2 Code inspection 6 4.3 Program analysis for important modules 6 4.4 Black box test 7
- 5. Summary of test result 8
- 6. Advice and constraints 9 Appendix A Applicable software Appendix B Test certificate no. 9451K 73004195 Report no.: 9451K 73004/95 Page 3 of 9
ISEB Non-proprietary Institute for Software. Electronics and Railway Technology Accredited in Europe
- Accepted around the world Version A TUV Rheinland 07/03/1995
- 1. Definition of task Following the creation of the new Serial Interface assembly NK 21 with galvanic isolation and new RS 485 interface, new improved software (part no. 3110 342 C) was customised to go with it. The supplementary type test of the NK 21 software is intended to prove that the changes to the software for the NK 21 serial interface have no effect on the component which has already been type-tested.
The basis for the modified software was the type-tested version 3110 342 B.
- 2. Codes and standards forming the basis of testing Type testing of electronic systems which form part of the reactor protection system is based on safety regulations laid down by the KTA (Nuclear Safety Committee):
- KTA 3501 Reactor protection system and safety system monitoring equipment (version 6/85)
- KTA 3505 Type testing of the reactor protection system's measuring sensors and measuring transducers (version 11/84)
There are no specific details or test procedures for software testing in KTA regulations 3501/3505. For this reason, the software test was primarily conducted on the basis of the report
[1]. Account was also taken of documents [2] to [4].
[1] Test concept for software for wide-range and power-range channel manufactured by Hartmann & Braun, for use in reactor protection systems (KTA 3501/3505)
(Report no. 945/K 71701188, revision A, date: 07/03/1988)
[2] DINVVDE 0801 Principles for computers in systems for safety functions, version January 1990
[3] Technical test report for digital wide-range channel DWK 250 software by Hartmann & Braun AG, Munich TUV Norddeutschland, report no. PB_DWK250_Software_160890, version 16/0811990
[4] Test report Docum entation of software test type-tested as per directive 26 on digital pulse channel DPK 251 manufactured by Hartmann & Braun AG, Munich TOV Rheinland, report no. 945/K 72001189, rev. A, version 06/09/1989 Report no.: 945/K 73004/95 Page 4 of 9
Non-proprietary Version ISEB Insitute for Softitre. Electronics and Railway'Technology Accredited in Europe mAccepted around the world A
TUV Rheinland 07103/1995
- 3. Test item 3.1 Documents and program source codes submitted for the test
[0] Software documentation Standard software for NK 21.2 and NK 21.1 part no.:
3110 342 C, version: 28/09/1994
[1] Short descriotion of the improved NK 21 software
(( ]1 version 2810911994
[2] Source code UART connection (( )) version 08104/1993
[3] Source code EPROM test (( )) version 2810911994
[4] Source code configuration data (( )) version 28/09/1994
[5] Source code S-Bus connection (( )) version 21/04/1993
[6] Source code main program )) version 08/0411993 Software NK 21 software Part no.: 3110 342 C, version: 22/0211995 Data carrier: Disk, Table of contents Appendix A EPROM, part no.: 3100 342 C K2001 Checksum: A6 5A The old documentation relating to connection of the host computer, and the description of the NK 21 software, continue to apply;, the short description [1] is just a supplem ent to these.
3.2 Equipment used
- 1. TK 250 measuring channel type DFK 251 without detectors with EPROM set DFK 251 3100 340C K7101 and modules N 111, NZ 21, NZ 12, NB 21, NA 06 and NK21.2.
- 2. Computer SKW-PC 80486, 33 MHz
- 3. Simulator for the 8051 family Simula 5X, version 2.03 '92 Report no.: 945/K 73004195 Page 5 of 9
N on-proprietary Version ISEB insitute for Software. Electmnics and Railway Technology' Accredited in Europe mAccepted around the world TUV Rheinland 07/03/1995
- 4. Development system Dr. Krohn & Stiller, B-51. version 4.3e
- 5. Various software tools
- Norton Commander, version 3.0
- Norton Utilities, version 5.0
- Delta, version 1.26 3.3 Test object The test object is the software realised in (( )) for the N K 21 serial interface of the TK 250 digital radiation monitoring system.
- 4. Conduct and results of test The software test was carried out in line with the testing guidelines in Section 2. In determining the individual stages of the test, the depth of testing was specified according to the rating for safety technology laid down in the technical test report [3].
4.1 Formal test The software documentation, consisting of the supplementary short description [1 ] and the source codes as supplied, was examined for intelligibilty, completeness and consistency.
The supplementary documentation is complete and consistent. It is only applicable in association with the previously checked documents. Cf. TOV Rheinland, report no. 945/K 72001189, rev. 1 and TOV Norddeutschland, report no. PB_ D WK250_ Software_ 160890.
4.2 Code inspection All module codes were inspected in dry run tests. These involved checking that the improvements described in the supplementary short description conformed to the coded program statements.
Checks were also made to ensure that there were no retroactive effects on previously implemented program parts.
No discrepancies were found between the supplementary documentation and the program source codes.
4.3 Program analysis for important modules The important modules of the modified software include the following program parts:
- Watchdog
- Time monitoring for the S bus
- EPROM monitoring Report no.: G45/K 73004195 Page 6 of 9
Non-proprietary Version Institute ISEB for Software, Electronics and Railway Technology Accredited in Europe
- Accepted around the world TUV Rheinland 07/03/1995 As all three program parts are being used for the first time in the modified software, a program analysis was carried out for them.
The program analysis involved observing the effects of the various configuration options on the fault control measures taken. It was concluded that the following points should be taken into consideration when configuring the software:
- 1. When determining bit labels for the S bus time monitor and the EPROM monitor it is important that port bits 0 - 5 are not available for an external message.
- 2. The control bytes for direction control for the NK21.1 and NK 21.2 both have different values.
NK 21.1 KSend 35 H K_Receive 37 H NK 21.2 KSend 37 H KReceive 35 H
- 3. The external fault messages 'S bus loss' and 'EPROM error' are active low.
The software simulator was used to support the program analysis.
The program analysis revealed no discrepancies between the documentation and the implemented software.
4.4 Black box test As the software for the NK 21 assembly transfers data telegrams 1:1 between the main processor and a connected host computer, and the changes made to the software have no effect on this, it was sufficient for the black box test to be a simple function test.
During the function test, both the V-24 and the RS 485 interfaces were tested.
Along with the function test, the fault control measures (watchdog, S bus monitor and EPROM test) were also examined.
All the implemented error detection measures behaved as described in the documents listed in Section 3.1.
Report no.: 9451K 73004/95 Page 7 of 9
Non-proprietary Version ISEB Institute for Software, Electronics and Railway Technology Accredited in Europe
- Accepted around the world a
TUV Rheinland 07/03/1995
- 5. Summary test result The following improvments have been realised in the revised NK 21 software:
- Program run monitored by external watchdog
- Time out monitoring for the s-bus based data transfer between NK 21 and NZ 12 board
- Monitoring of program memory
- Direction control for the RS 485 interface
- Improvements to line protocol processing The software test for the serial interface was conducted as a supplement to the already type-tested software with part no. 3110 342B.
As the software for the NK 21 serial interface has no functions for reactor protection, the following appropriate test steps were conducted:
- Formal test
- Code inspection
- Program analysis for important modules
- Black box test The supplementary software test showed that the changes which had been made had no retroactive functional effect on the parts of the software previously tested.
The test was carried out properly, in accordance with the testing guidelines. No faults were found which might argue against the use of the software for the exchange of data from the TK250 channels to other computer equipment.
A test certificate (see Appendix B) was issued, dated 1995/06/22.
The full manufacturer's documentation, the disk with the tested software and the test documentation remain at the test centre. The documentation in its entirety is stored in archive no.
945/K 73004/95.
Report no.: 945/K 73004/95 Page 8 of 9
Non-proprietary Version ISEB I insttute for Software, Electronics and Railway Technology Accredited in Europe
- Accepted around the world TOV Rheinland 07/0311995
- 6. Notes and constraints The N K21 software should be configured so that in the event of an EPROM error, the reaction is either to execute the stop loop with continuous triggering by the watchdog or effect a software reset. In the second case, the error message will have to be saved externally as the software reset will also reverse the internal error message. This ensures that any EPROM error cannot remain undetected.
During use of the serial interface, the NK 21 software does not monitor data telegram content.
In order to check the plausibility of the data telegrams, monitoring via a higher-level computer is required.
Data read from the serial interface should not be used to derive protective functions.
If the parameters of a channel are altered, a retrieval and a follow-up comparison should be carried out as described in the relevant system-specific user manual.
Cologne, 07/03/1995 ISEB/Kst.
945-ke-nie Authorised expert Dipl.-Ing. Klaus Kemp Report no.: 945/K 73004/95 Page 9 of 9
Non-proprietary Version TOV Rheinland ISEB 07/03/1995 Institute for Software, Electronics and Railway Technology Accredited in Europe n Accepted around tihe world Appendix A Valid program source codes for assembly NK 21 .x Part no.: 3110 342 C
((
1]
Non-proprietary Version ISEB A
TUV Rheinland Institute for Software. Electronics and Railway Technology Accredited in Europe . Accepted around the world 07/03/1995 Valid configuration for assembly NK 21.1 Configuration no.: K 1001 1]
Valid configuration for assembly NK 21.2 Configuration no.: K 2001
((
1]
Valid checksums over the full EPROM program code U[
Valid checksums over the full EPROM
((
11
1411 T- /a Non-proprietary Version MGPL,,H&B~~~~~~~hi~~~~~~
MGP4H&B~ Is n-proprieutayversionfr'om wh~ich
..... Mirion Technologies (MGPI H&B) GmbH te proprietary}NcerMaueen informdton has been removed according to 10 CIFR 2.390.NulaMesrmn-MnihGray uih emn In this document the removed sections of proprietary Infornation art indicated by two opening and two closing brackets as show" here.: r[ ))
Explanation of software article numbers The labeling of the software of the TK250 measuring systems is based on the H&B- norm WN105-202. This norm distinguishes between:
a) software original: archived source code and related documentation b) software on medium: data medium with executable program code (result of compiled
/ assembled source code) for usage within the TK 250 measuring system (EPROM's)
Corresponding to the H&B- norm the software original and the software on the data medium are signified through 2 homotropal number groups:
References from accompanying documentation (for example test protocols) to the "software original" are also valid for the "software on data medium" and vice versa.
Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89/ 51513-0 (MGPI H&B) GmbH D - 80687 MOnchen Fax: +49 (0)89 / 51513-169 Examine of Contents: 7- Author: MGPI-M, TBe Doc-no. 0348 573 B11E Formal Release: e Edition: 3 /2010-05-19 Page 1 von 1 Y:\Explanation of software article numbers 0348573 B11 E ed3.docx
/14 1T- 1.3'(a)
Non-proprietary Version MGPi1&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany This is a non-proprietary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are indicated by two opening and two closing brackets as shown here: (( 1]
Digital Wide Range Channel DWK 250 Specification and Description of the Software configuration no.: K012A Copyright 2011, Mirion Technologies (MGPI H&B) GmbH All rights, including rights patent and registered-design rights, where applicable, reserved. Transmittal, reproduction, or utilization of this document or disclosure of its content without expressed authorization by the copyright holder is prohibited. Violators shall be held liable for damages.
Doc-No. 023 180 B71E Edition: 1I I1 2011-09-08 2011-09-08 Page 1I of Page of 35 35 Doc-No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A Table of contents
- 1. In tro d u ctio n ................................................................................................................................. 3
- 2. DW K250 design ......................................................................................................................... 4 2.1. DWK 250 features .......................................................................................................... 4 2.2. Hardware structure .................................................................................................... 5 2.3. Software structure ...................................................................................................... 5
- 3. Description of the software configuration process ................................................................. 6 3.1. Configuring of the NZ 21 firmware .................................................................................. 7 3.2. Configuring of the NZ 12 firrrmware .................................................................................. 7 3.3. Verifying the configuration process ................................................................................ 8
- 4. List of configuration data ........................................................................................................... 14 4.1. Configuration parameters for the 10 processor software (NZ21) .................................. 14 4.2. Configuration parameters for the main processor software (NZ 12) .............................. 19 4.3. Display texts for the user interface ................................................................................ 25 4.3.1. Textgroup 0: (( ]........................................................................... 25 4.3.2. Textgroup 1: (( ]........................................................................... 26 4.3.3. Text group 2: (( ]........................................................................... 26 4.3.4. Text group 3: (( )) ......................................................... 27 4.3.5. Text group 4: (( ................................................. 27 4.3.6. Text group 5: [R 1].................................
........................................ 27 4.3.7. Text group 6: H )) ............................................... 27 4.3.8. Text group 7: (( 11................................................................ 27 4.3.9. Text group 8: (( - ............................................
- 28 4.3.10. Text group 9: (( .))...... 28 4.3.11. Text group 10: R ] ........................................................... 28 4.3.12. Text group 11: (( 11................................................ 28 4.3.13. Text group 12: (( ] ................................................. 29 4.3.14. Text group 13: (( ] ................................................. 30 4.3.15. Text group 14: (( ........................................................................... 31 4.3.16. Text group 15: [R ........................................................................... 31
- 5. List of changed and unchanged configuration parameters .................................................... 32 5.1. NZ 21 softrware .................................................................................................................. 32 5.1.1. Configuration data in file: (( .......................................................... 32 5.1.2. Configuration data in file: ........................................................ 32 5.1.3. Configuration data in file: ........................................................ 32 5.1.4. Configuration data in file: ] ........................................................ 32 5.2. NZ 12 software .................................................................................................................. 33 5.2.1. Configuration data in file: (( .......................................................... 33 5.2.2. Configuration data in file: ......................................................... 33 5.2.3. Configuration data in file: ......................................................... 33 5.2.4. Configuration data in file: ......................................................... 33 5.2.5. Configuration data in file: ......................................................... 33 5.2.6. Configuration data in file: ......................................................... 33
- 6. Revision history of this document ........................................................................................ 34 7 . Re fere n c e s ............................................................................................................................... 35 Edition: 1 / 2011-09-08 Page 2 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A
- 1. Introduction In 1988 Mirion Technologies (MGPI H&B) GmbH1 added the DigitalWide Range ChannelDW/K 250 to its product portfolio. The DWK 250 is designed for neutron flux measuring in source range, intermediate range and power range applications. With its set of configuration parameters the DWK 250 can be adopted to various measuring tasks. The core features of this product are described in chapter 2.1 of this document.
According to IEC 60880, chapter 7.1.4 a detailed list of the KO12A - configuration data is given in chapter 4 of this document. The configuration process is described in chapter 3.
DWK 250 DWK 250 with an With an German user interface English user interface Identification number for NZ 12 software 3110 489 A 3110 519 A Identification number for NZ 21 software 3110 490 A 3110 490 A Identification number for a set of application K0005 K01 2A specific configuration data Important note:
Both variants of the DWK 250 that are listed in the table above, contain exactly the same program code but have different sets of configuration data and a translated user interface to English. Thus the Software for the DWK 250 with the identification number 3110 519 A was created by replacing the existing configuration data (K0005) with a new and appropriate set of configuration data (KO12A) and a translated user interface to English, leaving the original DWK 250 program code unchanged (see chapter 3).
In 1988 Mirion Technologies (MGPI H&B) GmbH, Manchen was named Hartmann &Braun, KernstahlungsmesstechnikMonchen Edition: 1 / 2011-09-08 Page 3 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A
- 2. DWK 250 design 2.1. DWK 250 features For a detailed description and the features of the Digital wide range channel DWK 250 refer the user manual of the DWK 250, 5-0106 A70E edition 3.
The DWK 250 is equipped with microcontroller boards (NZ 12, NZ 21 and NK 21). These boards are based upon the Intel MCS 8051 microcontroller family (80C31, 80C32). In 1988 the application specific software for the DWK 250 was developed.
The components of the DWK 250 as well as the assembled channel have been type tested by TUV Nord in 1990 (see /5/, /60). The Software of this neutron flux channel was tested according to:
o KTA 3501 a KTA 3505 The DWK 250 contains a set of configuration parameters (configuration data). By setting these parameters to appropriate values of the neutron flux channels can be adopted to various application specific requirements. Thus many requirements can be met without changing the software.
During the construction process the configuration parameters are set to project specific values by the manufacturer (see chapters 3 and 4). They are stored in read-only memory chips (EPROM) at constant and well known address locations. These EPROMs are then placed on the processor boards within the neutron flux channels (NZ 12, NZ 21 and NK 21). Thus the configuration data cannot be modified on-line by plant operators.
2011-09-08 Page 4 of 35 Doc.No. 023 180 B71 E Edition: 11 /I 2011-09-08 Page 4 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 2.2. Hardware structure There are 3 types of programmable processor boards within the DWK 250:
o NZ 12 This user interface board is equipped with a keyboard, an alphanumerical display and several binary IO ports (see 11).
c NZ 21 This type of processor board is used for signal processing as well as analog and digital I/O tasks (see /2!).
o NK 21 This board provides a serial interface (RS232, RS485). The NK21-board is an optional feature of the DWK 250 channel.
All programmable processor boards within the DWK 250 are interconnected via a serial bus (S-BUS). They are all equipped with read only memory chips (EPROM) to store the processor board specific software (firmware) and configuration data.
Number of possible processor boards within the DWK 250 (see /4/).
Processor board type Number of processor boards NZ 12.2x 1 NZ 21.2x 1 NK 21.2x 0-1 2.3. Software structure Due to the fact that the DWK 250 contains 3 types of processor boards its software is divided into 3 separate programs (see fig. 1):
((1 Each of these programs defines a set of processor board specific configuration parameters (see configuration data in fig. 1). These parameters are stored along with the program code in read only memory chips (EPROM). Thus they cannot be changed at run time. The configuration data for the NZ 12 - and NZ 21 - software are listed in chapter 4 of this document.
Doc.No. 023 180 B71 E Edition:
Edition: 1 I/ 2011-09-08 1 2011-09-08 Page 5 Page of 35 5 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A DWK 250 - Software
((
11 Fig. 1
- 3. Description of the software configuration process It is the aim of the software configuration process to create two EPROM image files which contain the unchanged and type tested DWK 250 program code as well as the desired set of configuration data (see fig. 1).
An overview of the configuration process is shown in fig. 2. In this diagram an id number has been assigned to all files [Fl...F39], archive-sections [Al ...A4] and tools [Ti ...T6].
The DWK 250 reference source code files are stored in 2 separate software archive sections:
1]
These archive sections contain also the default configuration K0005 for both processor boards.
The new configuration (KO12A) is based upon these archived source code and configuration data files (see Al ...A2 in fig. 2).
of 35 Doc.No. 023 180 B7lE Edition:
Edition: 11 2011-09-08
// 2011-09-08 Page 6 Page 6 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 3.1. Configuring of the NZ 21 firmware All source code and configuration files (configuration sections in source files) (F23... F26) are copied from archive section (A2) to a project specific folder (F28... F31). In the next step the configuration parameters are set to create the configuration K012A for the NZ21 processor board. A detailed description of all configuration parameters can be found in chapter 4.1 of this document.
3t 3.2. Configuring of the NZ 12 firmware 1]
35 Doc.No. 023 180 B71 E Edition:
Edition: 1 // 2011-09-08 2011-09-08 Page 7 Page 7 of of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A 3.3. Verifying the configuration process All configuration parameters are stored at well defined fixed EPROM addresses. Program code and configuration data are stored in different areas of the EPROM (see fig. 1).
To verify the configuration process the following inspections and tests are carried out:
For NZ21:
. The new EPROM image file (F39) for NZ21 is compared with the reference EPROM image file (DWK 250 3110 490A K0005; F27). The resulting list of deviations is then analyzed to see if all deviations are located in the configuration data area of the EPROM (see fig. 1). In this case the new EPROM image file (F39) contains exactly the same program code as the corresponding reference EPROM image files (F27) with only changed configuration data area.
a In a second test the resulting list of deviations is analyzed to verify that the configuration parameters which are stored in the new EPROM image files (F27, F38) are set to the same values as the corresponding configuration parameters that are listed in chapter 4 of this document. Moreover the address locations of the configuration parameters are verified.
o An inspection is done to confirm that the configuration data are consistent with the design documentation and with any established constraints and rules o A number of practical test cases are carried out. The test cases are especially designed to show the effectiveness of the configuration parameters.
For NZ12:
o Since the user interface is translated to English, a compare of the resulting EPROM image files is not applicable. For this reason the source code files are compared to verify that only configuration data sections and text translations for the user interface are changed.
From all source code files the checksum is calculated and compared to each other. If the checksum is different, the source code file is compared in detail to verify the changes.
c In a second test the resulting list of deviations is analyzed to verify that the configuration parameters which are stored in the new EPROM image files (F22) are set to the same values as the corresponding configuration parameters that are listed in chapter 4 of this document.
An inspection is done to confirm that the configuration data is consistent with the design documentation and with any established constraints and rules o A number of practical test cases are carried out. The test cases are especially designed to show the effectiveness of the configuration parameters.
Edition: 1 / 2011-09-08 Page 8 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: KOl 2A Fig. 2 I/ 2011-09-08 Page 9 of 35 Doc.No. 023 180 B7lE Edition: 11 2011-09-08 Page 9 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A
((
I/ 2011-09-08 Page 10 of 35 Doc.No. 023 180 B71E Edition:
Edition: 11 2011-09-08 Page 10 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A
((]
Edition: 1 / 2011-09-08 Page 11 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A
((
Edition: 1 / 2011-09-08 Page 12 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A
((
Page 13 of 35 Doc.No. 023 180 B71E Edition: 1 I/ 2011-09-08 2011-09-08 Page 13 of 35 Doc.No. 023 180 B71 E
Wide range channel DVVK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A
- 4. List of configuration data The configuration parameters for the software configuration DWK 250 KO12A are listed in this chapter. The configuration parameters for the NZ 21 processor board are listed in chapter 4.1. The chapters 4.2 contain the configuration parameters for the NZ 12 processor board.
The chapter 4.3 contains the text translations from German user interface to English user interface.
In this chapter the property "default setting" represents the K0005 configuration parameter setting.
4.1. Configuration parameters for the 10 processor software (NZ21)
ORG 26H DISKR SCHW STARTWERT 11 Doc.No. 023 180 B71 E Edition: 2011-09-08 1 /I 2011-09-08 Page 14 Page of 35 14 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A FILTER EPS
((
1]
NIEDRIGSTERBEREICH, HOECHSTERBEREICH
((
1]
SPERRZEITLANG, SPERRZEITKURZ 1]
Page 15of35 Doc.No. 023 180 B71E Edition:
Edition: 11 /I 2011-09-08 2011-09-08 Page 15 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A OBERE SCHWELLE, UNTERE SCHWELLE RI 11 GRENZWERT TAB 1]
of 35 Doc.No. 023 180 B71 E Edition:
Edition: 2011-09-08 11 /I 2011-09-08 Page 16 Page 16 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A EPSILON 1]
SCHIEBEN 1]
EPS SKAL
[I 1]
Doc.No. 023 180 B71 E Edition: 2011-09-08 11 I/ 2011-09-08 Page 17of35 Page 17 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A ZHOS, ZLOS, ZHUS, ZLUS
((]
2011-09-08 Page 18 of 35 Doc.No. 023 180 B71 E Edition: 11 /I 2011-09-08 Page 18 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 4.2. Configuration parameters for the main processor software (NZ 12)
SOFTWARE IDTEXT meaning Identification string for the NZ 12 section of the DWK 250 software.
location (( ))
constraints String length is fixed to 32 characters. String characters are encoded in ASCII.
default setting 'DWK 250 3100 489 A K0005' K012A setting 'DWK 250 3100 519 A K012A' justification In 1988 the software for the DWK 250 wide range channel was build and type tested. This software consists of 2 separate processor board specific software packages. The identification number '3100 519 A' was assigned to the NZ 12 software package and is based on the type tested SW with the identification number '3100 489 A'.
This software package contains software configuration data in different areas of the program memory (EPROM). In 1997 a set of configuration data was predefined and type tested. It was assigned to the configuration identification number 'K0005'.
For the MIT an application specific set of configuration data with the id number
'3100 519 A' has been defined. Its configuration identification number is
'KO12A'. The resulting software identification string therefore is:
'DWK250 3100 516 A K012A'.
AIF EPROM STORED CHECKSUM
))
Edition: 1 / 2011-09-08 Page 19 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A C REAL PARAMETERS
))
Page 20 of 35 Doc.No. 023 180 B71 E Edition:
Edition: 11 /I 2011-09-08 2011-09-08 Page 20 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A 1]
C VARPOOL DIMENSION
((
))
35 Doc.No. 023 180 B71E Edition:
Edition: 1 I/ 2011-09-08 2011-09-08 Page 21 of Page 21 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A C MESSSTELLENKZ
[E 1]
Doc.No. 023 180 B71 E Edition:
Edition: 1 /I 2011.09-08 2011-09-08 Page 22 Page of 35 22 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the softvare configuration no.: K012A C GRENZWERTE of 35 Doc.No. 023 180 B71 E Edition: 1 I/ 2011-09-08 1 2011-09-08 Page 23 Page 23 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A C SCHREIBER PARAMETER
((
))
2011-09-08 Page 24 of 35 Doc.No. 023 180 B71 E Edition: 11 // 2011-09-08 Page 24 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A 4.3. Display texts for the user interface The user interface of the DWK 250 is based on an alphanumeric display with 2 x 16 characters and a keyboard with eight keys. A detailed description of the user interface is given in the user manual (see /3/).
All of the user interface functions are provided by the NZ 12 software. Other processor boards do not contribute to the user interface.
The constant text strings for the alphanumeric display are stored in an EPROM which is located on the NZ 12 board. Most of the strings are defined in the source file called "WMTTBO.P51". Within this file the text strings are divided into 15 different text groups. They are named TGRO, TGR1 ...
TGR15.
A complete translation of the user interface into a different language (English, French ...) is done by translating the text strings listed in the text groups TGRO ... TGR15.
The character set for the display texts is listed below (ASCII encoding):
A B C D E F G H I J K L MN 0 P Q R S T U V WX Y Z a b c d e f g h i j k I m n o p q z t u v w x y z 0123456789+-* / .: <>? ! ( ) %=
The software for the Digital Wide Range Channel DWK 250 was developed in 1988. The language for the user interface in this initial software configuration is German.
The English translations of the text groups TGRO ... TGR15 are listed in the following chapters:
o The column "German" contains the original display texts as defined for the software configuration "DWK 250 3110 489 A K0005" in 1988.
o The column "English" contains the translated text for the software configuration K012A.
4.3.1. Textgroup 0: (( ))
Reference:
DWK 250, User Manual maximal string length: 12 character
((
))
Edition: 1 / 2011-09-08 Page 25 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A 4.3.2. Textgroup 1: [H 1]
Reference:
DWK 250, User Manual 11 4.3.3. Text group 2: (( ))
Reference:
DWK 250, User Manual, Chapter 5.6.1 Maximal string length: 16 characters
((
of 35 Doc.No. 023 180 B71 E Edition: 2011-09-08 11 /I 2011-09-08 Page 26 Page 26 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 4.3.4. Text group 3: [1 11
Reference:
DWK 250, User Manual maximal string length: 3 characters
((
1]
4.3.5. Text group 4: (( 11
Reference:
DWK 250, User Manual maximal string length: 1 character
[R 4.3.6. Text group 5: (( 11
Reference:
DWK 250, User Manual maximal string length: 3 characters 1]
4.3.7. Text group 6: [R 1]
Reference:
DWK 250, User Manual, Chapter 5.7.4 maximal string length: 16 characters
((
4.3.8. Text group 7: [1 )) 11
Reference:
DWK 250, User Manual, Chapter 5.7.2 maximal string length: 16 character
((
1]
Page of 35 Doc.No. 023 180 B71 E Edition:
Edition: 1 /1 2011-09-08 1 2011-09-08 Page 27 27 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 4.3.9. Text group 8: (( ))
Reference:
DWK 250, User Manual, Chapter 5.7.2 maximal string length: 16 character
((
4.3.10. Text group 9: [R 1] I]
Reference:
DWK 250, User Manual maximal string length: 14 character 4.3.11. Text group 10: (( )) ii
Reference:
DWK 250, User Manual, Chapter 5.7.3 maximal string length: 16 characters
((
4.3.12. Text group 11: (( ]
Reference:
DWK 250, User Manual, Chapter 5.7.3 maximal string length: 16 characters 11 1]
2011-09-08 Page 28 of 35 Doc.No. 023 180 B71 E Edition: 1 /I 2011-09-08 Page 28 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 4.3.13. Text group 12: ((
Reference:
DWK 250, User Manual, chapter 2.6 maximal string length: 2 x 16 characters 1]
Page 29 of 35 Doc.No. 023 180 B71 E Edition: 1 I/ 2011-09-08 1 2011-09-08 Page 29 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 4.3.14. Text group 13: (( ))
Reference:
DWK 250, User Manual maximal string length: 2 x 16 characters I]
Edition: 1 1 2011-09-08 Page 30 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A 4.3.15. Text group 14: (( 1]
Reference:
DWK 250, User Manual
((
11 4.3.16. Text group 15: (( 1]
Reference:
DWK 250, User Manual maximal string length: 1 character
((
2011-09-08 Page 31 of 35 Doc.No. 023 180 B71E Edition: 11 // 2011-09-08 Page 31 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A
- 5. List of changed and unchanged configuration parameters An overview of the changed and unchanged configuration parameters is given in this chapter. The following tables show the results of a comparison between the parameters set in configuration K012A and the reference configuration K0005. In these tables a parameter is marked as unchanged if it is set to the same value(s) in both configurations (K0005 & K012A).
5.1. NZ21 software 5.1.1. Confiquration data in file: (( ))
((
1]
5.1.2. Configuration data in file: (( 1]
[I 11 5.1.3. Configuration data in file: (( 1]
((
11 5.1.4. Confiouration data in file: H 1]
2011-09-08 Page 32 of 35 Doc.No. 023 180 B71 E Edition: 11 /I 2011-09-08 Page 32 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A 5.2. NZ 12 software 5.2.1. Configuration data in file: (( ))
Since the user interface text strings have been translated into English text strings almost all parameters in (( )) have been changed.
6.2.2. Configuration data in file: (( ))
Since the user interface text strings have been translated into English text strings almost all parameters in [f )) have been changed.
5.2.3. Configuration data in file: (( ))
Since the user interface text strings have been translated into English text strings almost all parameters in (( )) have been changed.
5.2.4. Configuration data in file: (( ]
5.2.5. Configuration data in file: (( ))
5]
5.2.6. Configuration data in file: ((: ))
[II
))
2011-09-08 Page 33 of 35 Doc.No. 023 180 B71 E Edition: 1 I/ 2011-09-08 Page 33 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K012A
- 6. Revision history of this document fchapters Edition Release date iIDescription of the modification affected 1 2011-09-08 First released version all of 35 Doc.No. 023 180 B71E Edition: 2011-09-08 11 // 2011-09-08 Page 34 Page 34 of 35 Doc.No. 023 180 B71 E
Wide range channel DWK 250 for the MIT, Cambridge, USA Non-proprietary Version Specification of the software configuration no.: K01 2A
- 7. References
/I1 Main Processor NZ 12.2 Technical Information Doc. no. 5-0251 V10E Mirion Technologies (MGPI H&B) GmbH, Munich
/2/ VO-Processor NZ21.2 Technical Information Doc. no. 5-0260 V10E Mirion Technologies (MGPI H&B) GmbH, Munich
/3/ DWK 250/ 5-0106 User Manual Doc. no. 5-0106 A70E Mirion Technologies (MGPI H&B) GmbH, Munich
/4/ DWK 250 / 5-0106 Specification / Technical Information Doc. No. 5-0106 V10 Mirion Technologies (MGPI H&B) GmbH, Munich
/5/ Test Certificate for Digital Wide Range Channel DWK 250 - Software -
June 1990 TUV Nord e.V., Hamburg
/6/ Technical Test Report for the Digital Wide Range Channel DWK 250 - Software -
June 1990 TOV Nord e.V., Hamburg
/7/ List of default parameters for DWK 250 K01 2A Doc. no.: 023180 L71E Mirion Technologies (MGPI H&B) GmbH, Munich
/8/ Interface specification for DWK 250 K01 2A Doc. no.: 023180 B70E Mirion Technologies (MGPI H&B) GmbH, Munich Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 M~znchen Fax: +49 (0)89 51513-169 Examin. of contents: sign. BH Author: MGPI-SW, Ter Doc-No. 023 180 B71 E Formal release: sign. CR Page 35 von 35 Edition 1 / 2011-09-08 P tedlung 5- 11A31 ~specifion.o¢n He: G 'P'oel..kedin. Pivj,? -nroirnutjonP3q Aktell'12231$ lTVv , e- InrgtrIf DOkutrir4n Vnu6u. A[l K 0 12,Cotifig-w tion 2'OW 02318-0 B71E edl.d DIX
Version Non-proprietary MGPl&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement - Munich, Germany Information This Is a non-proprietary version Ifrom which the proprietary has been removed according to 10 CFR 2.390.
in this document the removed sections of proprietary inforrm.ion ae Indicated by two opening and two closing DWK 250 K01 2A brackets a shown here: 11 Interface Specification Softwa re-Designatio n: DWK 250 3110 519 A K012A (NZ 12)
Software reference no.:
3110 490 A K012A (NZ 21)
Customer: MIT, Cambridge, USA Project: Wide Range Channel Order no.: 023180 Type of modification: - Application specific software configuration
- English user interface Technical Data:
Calibration:
Neutron flux calibration factor CF= 1.0 [default setting)
NZ21 Analog input signals:
- Signal Al 1 Detector signal 0... 10V, representing the detector signal / Campbell signal Al 2 Detector voltage 0... IyV, representing the detector voltage in the range 0... 1000V Al 3 Internal operating voltage 0... 10V, representing the internal operating voltage of the channel Al 4 Discriminator threshold 0... 10V, representing the discriminator voltage from the NI 21.21 NZ21 Analog output signals:
- Signal AO 1 Neutron Flux 0... 10V representing a neutron flux of le-6 ... 200 %Pn1 , log. scale AC 2 Flux change rate 0... 10V representing a flux change rate of -0.0333 ... +0.1 1/s12 AC 3 Discriminator threshold 0... 5 V AC 4 Linear count rate 0... 10V representing a count rate of 0 ... 5e+5 cps; not connected The parameters of the analog outputs AO1 and A02 can be changed by the operational staff (see manual).
2 Flux change rate of -0.0333... +0.1 1/s <-> Period: -30 s ... Go... +10 s; {where: Flux change rate = 1 / Period}
Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Munchen Fax: +49 (0)89 51513-169 Examin. of contents: sign. BH Author: MGPI-SW, Ter Doc-No. 023180 B70E Formal release: sign. CR Page 1 von 2 Edition 1 / 2011-09-08 Mitteilung 5-11281 uell\023180 MfTWde Range tnstr\80Dokumentation\juellen'DVWf File: G :rojekte\Techn. Projekt-lnformation\PJK-A<TA 250 K012A Interface specification 023180 N0OEedl.docx
DWK 250 K011 A Non-proprietary Version Interface specification NZ 21 Alarms:
((
11 NZ 12 Alarms:
[I 11 Measuring ran-ges:
If
- Number of measuring ranges:
- Lower threshold for range switching:
- Upper threshold for range switching:
11 Doc.No. 023180 B70E Edition:
Edition: 2011-09-08 11 /I 2011-09-08 Page 2of2 Page 2 of 2 Doc. No. 023180 B70E
Non-proprietary Version Nn1p-- IVeri(;)
MGPt-&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement - Munich, Germany Parameter list DWK 250 3100 519 A K012A This Is a non-proprietary version from which the proprietary Digital wide range channel Information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary Information are Indicated by two opening and two closing brackets as shown here: (( ))
Customer: MIT, Cambridge, USA Order - No.: 023180 Detector:
- Default value - - Actual value -
- 1. Plantcode:
- 2. Generalsettings:
((I
))
- 3. Time constants:
))
- 4. Voltage monitoring:
1]
Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Minchen Fax: +49 (0)89 51513-169 Examin. of contents: sign. BH Author: MGPI-SW, Ter Doc-No. 023180 L71E Formal release: sign. CR Page 1 von 4 Edition 2 / 2011-11-29 Mitteflung 5-11310 MiT 'ide Range Instrl80 Dokumentation\QuellenCDWK 250 K012A List of parameters File: G Projekte\Techn Projekt-InformationPXJT Al tue1I\023180 023180 L71E ed2.docx
Non-proprietary Version Digital Wide Range Channel DWK 250 Parameter list for DWK 250 K012A
- Default value - - Actual value -
- 5. Alarms:
[I Doe. no.: 023180 L7IE Edition:
Edition: 22 2011-11-29
/I 2011-11-29 Page 2of4 Page 2 of 4 Doc.no.: 023180 L71E
Non-proprietary Version Digital Wide Range Channel DWK 250 Parameter list for DWK 250 K012A
- Default value - - Actual value -
- 6. Analog outputs:
- 7. Select dimensions:
((
))
Doc. no.: 023180 L71E Edition: 2011-11-29 22 /I 2011-11-29 Page 3 Page of 4 3 of 4 Doc. no.: 023180 L71 E
Non-proprietary Version Digital Wide Range Channel DWK 250 Parameter list for DWK 250 K01 2A EPROM - Parameters NZ2 1):
- 8. Pulse path:
1))
- 9. AC path:
((
- 10. NZ 21 based alarms:
The three NZ 21 based alarms (Alarm 0, 1 and 2) are not used in this software configuration. They are thus disabled. This is done by setting their threshold levels accordingly.
[I 11 Note: Alarm 2 is not effective in measuring range #12.
Dec. no.: 023180 L71E Edition: 22 // 2011-11-29 2011-11-29 Page 4of4 Page 4 of 4 Doc.no.: 023180 L71E
m1i -r- 13(d)
Non-proprietary Version MGP-iH&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany 1
I This is a non.propretary version from which the proprietary information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary Information are Indicated by two opening and two closing 3 brackets as shown here: f[ 1] 1 Verification plan-and protocol for DWK 250 Software Configuration No.: KO12A Software: DWK 250 Software Identification No.: 3100 490A KO12A (Firmware for NZ21 board) 3100 519 A KO12A (Firmware for NZ 12 board)
Customer: MIT, Cambridge, USA Order No.: 023 180 Copyright 2011, Mirion Technologies (MGPI H&B) GmbH All rights, including rights patent and registered-design rights, where applicable, reserved. Transmittal, reproduction, or utilization of this document or disclosure of its contents without expressed authorization by the copyright holder are prohibited. Violators shall be held liable for damages.
Mirion Technologies Landsberger Stir. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Munchen Fax: +49 (0)89 51513-169 Examin. of contents: Author: MGPI-SW, Ter Doc-No. 023180 F70E Formal release: i10 Page 1 von 30 Edition 1 / 2011-09-08 MIatelurg 5-11201 File:Y:%Tl251M=
TNFL 0231e801Kna*8ell(" 250(,012AOokuLDWK 250 K012A VErficOtion plan and protmd 023100 FT0E edl.doci
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A Table of Contents
- 1. Intro d uc tion ................................................................................................................................. 3
- 2. Verification strategy ........................................................................................................... 3
- 3. Execution of the verification ........................................................................................................ 4 3.1. Verification of the NZ 12 configuration data ................................................................... 4 3.2. Verification of the NZ21 configuration data ................................................................... 12 3.3. Judgment for the results of the software analysis .......................................................... 16 3.4. Practical tests ................................................................................................... ... 17 3.4.1. List of participating persons ................................................................................... 17 3.4.2. List of measuring instruments ................................................................................. 17 3.4.3. List of DW K 250 modules ..................................................................................... 18 3.4.4. Verification of the EPROM label text ...................................................................... 18 3.4.5. Verification of the EPROM checksums ................................................................. 19 3.4.6. Verification of the translated user interface text strings .......................................... 19 3.4.7. Verification of the Software Identification string ..................................................... 22 3.4.8. Verification of the Analog Outputs ......................................................................... 22 3.4.9. Verification of the range switching thresholds ........................................................ 24 3.4.10. Verification of the enabled measurement ranges .............................................. 24 3.4.11. Verification of the measuring range time-lock settings ....................................... 25 3.4.12. Verification of the selectable dimensions ......................................................... 25 3.4.13. Verification of the default parameter settings ..................................................... 26 3.4.14. Compare NZ12/NZ21 EPROM with corresponding EPROM image files ........ 27 3.5. Judgment for the results of the practical tests ............................................................... 28
- 4. Revision history of this document ....................................................................................... 29
- 5. Re fe re n ce s ............................................................................................................................... 30 30 Doc.No.: 023180 F7OE Edition:
Edition: 11 I/ 2011-09-08 2011-09-08 Page 2 Page 2 of of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A
- 1. Introduction This document contains the verification plan and protocol for the configured software:
DWK 250 KO12A.
A detailed description of DWK 250 and its software is given in the user manual (see /3/). The configuration data for this software is described in the document: "Digitalwide range channel DWK 250: Specification and description of the Software configurationno. "W(012A" (see 110/).
((1
- 2. Verification strategy The systematic verification strategy consists of the following elements:
- 1. Inspection of the specified configuration data
- 2. Inspection of the changed / configured source code files
- 3. Verification of the configuration data:
i.e.: Confirm that the EPROM image files contain the specified configuration data
- 4. Practical tests i.e.: Prove the correctness of the configuration data as well as the DWK 250 measuring system in its entirety Edition: 1 / 2011-09-08 Page 3 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A
- 3. Execution of the verification The program code for the DWK 250 was type tested in 1990 (see 151, 161). The reference configuration and the type tested software are stored in the archive sections (( )) (for the NZ21 processor board) and archive section (( )) (for NZ12 processor board).
It is the aim of this verification procedure to show that the new software files for the DWK 250 contain exactly the type tested DWK 250 reference program code and the configuration is consistent with the specified configuration parameters (see /10/).
3.1. Verification of the NZ 12 configuration data Since the user interface of the DWK 250 is translated to English in the course of this new software configuration, the differences in the length of the German and English UI text strings prevent a comparison of the resulting Intel HEX file with the original Hex file for the software of the NZ12 processor. For this reason all software files of the NZ12 processor are checked for changes by calculating the checksum of the reference files and the new software files for the configuration KO12A. In those cases, where the checksum of the new software file deviates from the checksum of the corresponding reference file, both file (i.e. the new and the reference file) are compared in detail on the source code file level, to verify that only text strings and configuration data are changed in the modified software file.
If all deviations meet these requirements then the new software files for the DWK 250 contain exactly the type tested DWK 250 reference software.
Table of source files and checksums:
CRC32 - Checksum CRC32 - Checksum Source file of the original SW of the translated SW changed Judgment (DWK 250 3110 489A) (DWK 250 3110 519 A)
I]
Edition: 1 / 2011-09-08 Page 4 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A CRC32 - Checksum CRC32 - Checksum Source file of the original SW of the translated SW changedI Judgment (DWK 250 3110 489A) (DWK 250 3110 519 A) 11 Comparison result of [H 11 1]
Doc.No.: 023180 F7OE Edition:
Edition: 2011-09-08 11 1,' 2011-09-08 Page 5 Page of 30 5 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 11 Comoarison result of (( 1]
1[
1]
Comrarison result of (( 1]
11 Comparison result of 1]
1]
Edition: 1 / 2011-09-08 Page 6 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A
((
1]
Comparison result of (( 1]
[1 11 Page 7 of 30 Doc.No.: 023180 F7OE Edition:
Edition: .1 // 2011-09-08
- i 2011-09-08 Page 7 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A Edition: 1 / 2011-09-08 Page 8 of 30 Doc.No.: 023180 F70E
and protocol Non-proprietary/Version Verification plan Digital wide range channel DWK 250 K012A Comrcarison result of [ ))
((:
))
Edition: 1 / 2011-09-08 Page 9 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A Edition: 1 1 2011-09-08 Page 10 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A Edition: 1 / 2011-09-08 Page 11 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K01 2A Requirements to pass this test: All deviations shall either be related to the configuration data of the configuration K012A or have to be caused by the translation of the user interface text strings to English. All files which have changed (different checksum) are compared in detail and only text strings and text string relevant values are changed in this source files. The changes of the configuration data are also compared and listed in this test. The changes of the configuration data are tested in chapter 3.2 and in chapter 3.3 in this document.
Judgment 0 hr. I-3.2. Verification of the NZ21 configuration data Confirm that the NZ21 EPROM image files contain the specified configuration data and the type tested code The configuration parameters for the software configuration for the DWK 250 with the identification number "3100 490 A K01 2K are specified in /10/. These parameter settings are expected to be stored in the correct addresses of the NZ21 EPROM. It is the aim of this test procedure to verify that the actual configuration parameters in the EPROM image files ("WAOH01.2A") do not deviate from the specified configuration parameter settings (see /10/).
This comparison is carried out by using the MGPI tool "HEXCOMP.EXE". It reads the content of the files to compare and creates a list of found deviations. This list is then stored in a simple text file.
As shown in fig. 2 the resulting text files are then copied to the appropriate sections of the verification protocol. To pass this test the following rules must be applied:
o Every configuration parameter that is marked as "changed" must be enlisted in the list of deviations. The configuration data which are listed at its given EPROM address location must match the specified configuration data.
o Every configuration parameter that is marked as "unchanged" (see chapter 5 in /10/) is either not contained in the list of deviation at all or is contained in it but in this case with identical configuration data for K0005 and K012A 1.
1For every found deviation the MGPI tool "HEXCOMP.EXE" adds at least 16 bytes of consecutive EPROM data to the list of deviations. These bytes might as well contain unchanged configuration data.
of 30 Doc.No.: 023180 F7OE Edition: 11 /I 2011-09-08 2011-09-08 Page 12 Page 12 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A Comparison for NZ 21 firmware
((:
))
Page 13 of 30 Doc.No.: 023180 F7OE Edition:
Editioný 1I 2011-09-08 1/ 2011-09-08 Page 13 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A NZ21 hex-file compares result:
Compare results for the HEX files:
[I:
11 Requirements to pass this test: The specified configuration parameter settings are correctly and completely implemented in the new software configuration K012A. All deviations between the reference configuration K0005 and the new configuration can be justified as specified configurations parameter settings.
Judgment 0 /< &-
Edition: 1 / 2011-09-08 Page 14 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 1]
Edition: 1 / 2011-09-08 Page 15 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3,3. Judgment for the results of the software analysis Judgment:
1(000 9 are 4i&.
Veo/( OAD( !We C-rc4-/e/ UV..h#-e C. A.e
-DkI/r Pro KO0 r7tv ev-. /,n..,4 -~eh~Pts -4co4 e
-re/fer eg ce ccrW/is (,, P-ra KaOd,0 7Z4 TA&g 49 /r../,
1e,.,~' z,,J ,..o Country / City:
Date:
?0. a 9F~
0 .9. PoC Examiner:
F.gdb7-e,4'/7e/
Signature:
of 30 Doc.No.: 023180 F7OE Edition: 1 I/ 2011-09-08 1 2011-09-08 Page 16 Page 16 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.4. Practical tests The practical tests for the Digital wide range channel DWK 250 with software configuration K012A are described in this chapter. General overviews for the device under test (DUT) are given in the arrangement diagram and in the circuit diagram of the channel (see /8/). Further details are provided by the user manual /3/. The interfaces of the DUT are described in /71.
3.4.1. List of participating persons All persons participating in this test are listed in the following table:
- Name First name Company 2
3 l _
3.4.2. List of measuring instruments The test equipment (measuring instruments, test signal generators, etc.) which is used during this test is listed in a separate table:
Purpose:
Device name Manufacturer Calibration The device is used as and type valid until 1 Test signal generator /"FC".7022 a 7e'.k 60At 2 Multi-meter F/6e 241 U eO ,1/,k .
3 __________ T.a* 483/, i ,*f .o,*
4 ,..t______&_f 4
7 8 ___________
9 ____________ _____________ _________ __________
of 30 Doc.No.: 023180 F7OE Edition:
Edition: 11 /I 2011-09-08 2011-09-08 Page 17 Page 17 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.4.3. List of DWK 250 modules As shown in the arrangement diagram the DUT consists of different electronic modules. For documentation purposes a complete list of all modules that are contained in the DAK 250 is created in this test step. The list of modules contains the following columns:
o Location Location of the module within the DWK 250 o Type Module name (example: NZ 21.22, NZ 12.21, ... )
o Ref.-no. ID number of the module type (Sach / Zeichnungs-Nr) o Serial no. Individual serial number for the module (F-Nr.)
- Location Type Ref. no. Serial no.
1 2
3 4
5 6
7W 8 ___
9 10 C",___
11 . .,__"
12 13 ,_ _ _ _ _
14 ___._
15 16 _ _
17 18 j 3.4.4. Verification of the EPROM label text The NZ 12.21 and NZ 21.22 processor boards are both equipped with an EPROM chip. The labels on these chips are compared with the reference labels shown below:
a) NZ 12.21 - EPROM label text (reference):
13100 519 A K012A NZI2.2 U3 DWK 250 0 MGPI 1997, 2011 b) NZ 21.22 - EPROM label text (reference):
13100 490 A K012A NZ21.2 D26 DWK 250
© MGPI 1997 Requirement to pass this test: The text on the EPROM labels shall not deviate from the text listed above.
Judgment I a sk.
Edition: 1 1 2011-09-08 Page 18 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.4.5. Verification of the EPROM checksums The NZ 12 and NZ 21 software periodically computes a CRC checksum value for the content of the corresponding EPROM. The user interface dialogue "Checksums" shows these values on the DUTs display. In this test the actual values are compared with the reference values (see T3, T6 in fig. 3).
For this test the following series of operations has to be carried out:
o If the DUT is switched off then switch it on and wait approximately 5 minutes o On the user interface select the column "Diagn. Values" o Press the "Down" key until the NZ 21 checksum is shown on the channels display o Verify and note the NZ 21 checksum
,o Press the "Down" key again
" The DUT now shows the checksum for the NZ 12 EPROM on its display o Verify and note the NZ 12 checksum Reference value Actual value Checksum for NZ 12 - EPROM: 15A7 ,5-R2 Checksum for NZ 21 - EPROM: 5862 .5-8_6_2_
Requirements to pass this test: The actual checksum values shown on the DUT display shall not deviate from the reference values listed above. No checksum fault is shown in the failure list of the channel.
Judgment 04. 4 "
3.4.6. Verification of the translated user interface text strings The text strings for the user interface have been translated into English. The English text strings are listed in table below and in the configuration specification document /10/. To verify the correct translation of the user interface text strings the display texts of the DUT are compared with the specified text strings in the table below.
For this test the following series of operations has to be carried out:
o Select all user interface text strings on the DUT's display and compare the text strings that are shown on the display with the text strings that are shown in the table below
((:
Edition: 1 / 2011-09-08 Page 19 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A
((
1]
Edition: 1 / 2011-09-08 Page 20 of 30 Doc.No.ý 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 11 1]
Requirement to pass this test: The text strings that are shown on the display of the DUT shall not deviate from the specified text strings in table above.
Judgment O1'.
Edition: 1 1 2011-09-08 Page 21 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.4.7. Verification of the Software Identification string The identification string for the NZ 12 software is stored in the configuration parameter "SOFTWAREIDTEXT". The user interface dialogue "Software Ident." shows the content of this string on the display of the user interface. The displayed string is then compared with the reference string in table below.
For this test the following series of operations has to be carried out:
o Select the user interface dialogue "Status" / "Software Ident.:"
o Press the "enter / next" key 2 on the DUT keyboard o Upon pressing this key the DUT displays the requested ID string ID as shown on Reference the user interface display Software identification string: DWK 250 D17W J SO 3100 519 A K012A 24 00 5W3f#9 A0d2P Requirement to pass this test: The ID string shown on the DUT display shall not deviate from the reference value listed above.
Judgment 3.4.8. Verification of the Analog Outputs This test is meant to verify the correct function of the analog outputs and the configuration data CSCHREIBERPARAMETER. The analog outputs can be checked by the correct analog output parameterization of the analog outputs itself and by setting of the corresponding measurement value. This test is subdivided into two subsections. One test for the analog output 1 for the logarithmic scaled neutron flux measurement value and the second one for the analog output 2 for the RELFAG signal.
I. Neutron flux
))
The names of the user interface keys are listed in user manual Edition: 1 / 2011-09-08 Page 22 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A
[I 1]
II. RELFAG 1]
Requirement to pass this test: The deviations between the measured values and the corresponding reference values shall not exceed the tolerance limits of the DUT.
Judgment 1 4. C--,
Page 23 of 30 Doc.No.: 023180 F7OE Edition:
Edition: I1 /I 2011-09-08 2011-09-08 Page 23 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.4.9. Verification of the range switching thresholds This test is meant to verify the configuration parameters [
)) (see /7/ and chapter 4.1 in /10/):
For this test the following series of operations has to be carried out:
((
))
Requirement to pass this test: The lower threshold for the range switching is set to 0.60 V and the upper range switching threshold is set to 2.50 V.
Judgment .G.
3.4.10. Verification of the enabled measurement ranges This test is meant to verify the configuration parameters (( 1] and
(( )) (see /7/ and chapter 4.1 in /10/):
For this test the following series of operations has to be carried out:
[t I]
Requirement to pass this test: No measuring range is locked. Thus all 16 measuring ranges can be used by the DWK 250 K012A.
Judgment 9k &. I Rewte-rk : 'Qe/76r 3-ea~
J' 7' k 313V1111e ,B easutil Irethye 4
( lig 4 c-; A14 21)
Page 24 of 30 Doc.No.: 023180 F7OE Edition:
Edition: 2011-og-08 11 1I 2011-09-08 Page 24 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.4.11. Verification of the measuring range time-lock settings This test is meant to verify the configuration parameters (( ]I and
(( )) (see /7/ and chapter 4.1 in /10/):
For this test the following series of operations has to be carried out:
((I Information about the range switching test:
Judgment vk.
3.4.12. Verification of the selectable dimensions This test is meant to verify the selectable dimensions:
For this test the following series of operations has to be carried out:
o On the user interface of the DWK 250 select the dialog "Parameters / Select dimensions:"
o Enter this dialog and verify that the following dimensions can be selected:
ri 1]
Requirement to pass this test: The listed dimension can be selected in the dialog "Select dimensions".
Judgm ent I lf-. t I Edition: I / 2011-09-08 Page 25 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.4.13. Verification of the default parameter settings The aim of this test is to verify that the DUT default parameters do not deviate from the specified default parameters (see /9/ and /10/). For this purpose the default parameters are loaded in the DUT, recorded and compared with the specified default parameters.
For this test the following series of operations has to be carried out:
o If the DUT is switched off then switch it on o Select and execute the user interface dialogue "Parameters"!"Defaultparameters:"' "Load default parameters".
o Record the actual parameter values in the table shown below Parameter name Default value Actual value Judgment General settings:
((
I Voltage monitoring:
11 IAlarms:
((
1]
--- (not used) ._ý_
AL 2... AL 16: I Edition: 1 / 2011-09-08 Page 26 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A I
Parameter name Default value Actual value I Judgment Analoq outputs:
((
11 I Plant code:
Code =
Requirement to pass this test: The actual parameter values shall not deviate from the specified default values (see /9/).
Judgment 1 0V 1" 3.4.14. Compare NZ121NZ21 EPROM with corresponding EPROM image files The purpose of this test is to verify that the software in the DUT does not deviate from the EPROM image files "WMOH01.1A" and "WAOH01.1A" (i.e. F22 and F39 in fig. 3).
For this test the following series of operations has to be carried out:
((1 Requirement to pass this test: The EPROM contents and the Intel Hex files must be identical.
I Judgment oi.
Edition: 1 / 2011-09-08 Page 27 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A 3.5. Judgment for the results of the practical tests Judgment:
1.til
/I- .1 RI PMerev e~ers A.'ewe_ &,Afi~e Mef The led!ýPefca 1:
Country / City:
Date: 29.dvafc. ?6w4 Examiner:
Signature:
Edition: 1 / 2011-09-08 Page 28 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 K012A
- 4. Revision history of this document Page 29 of 30 Doc.No.: 023180 F7OE Edition: 2011-09-08 11 /I 2011-09-08 Page 29 of 30 Doc.No.: 023180 F70E
Non-proprietary Version Verification plan and protocol Digital wide range channel DWK 250 KO12A
- 5. References Ill Main Processor NZ 12.2 Technical Information Doc. no. 5-0251 V10E Mirion Technologies (MGPI H&B) GmbH, Munich 121 110-Processor NZ21.2 Technical Information Doc. no. 5-0260 V1OE Mirion Technologies (MGPI H&B) GmbH, Munich
/3/ DWK 250 User Manual Doc. no. 5-0106 A70 Mirion Technologies (MGPI H&B) GmbH, Munich 141 DWK 250 Specification / Technical Information Doc. No. 5-0106 D22E Mirion Technologies (MGPI H&B) GmbH, Munich 151 Test Certificate for Digital wide range Channel DWK 250 - Software -
Certificate No. 1225068496 / 01 May 1990 TUV Nord, Hamburg
/6/ Technical Test Report for the Digital wide range Channel DWK 250 - Software -
May 1990 TUV Nord, Hamburg
/71 Interface Specification for DWK 250 KO12A Doc. No. 023180 B70E Mirion Technologies (MGPI H&B) GmbH, Munich
/8/ Arrangement diagram and Circuit diagram for the Digital wide range channel DWK 250 Doc. no. 5-8631 G10 and 5-8631 P10 191 Parameter list for DWK 250 K012A Doc. no.: 023180 L71E Mirion Technologies (MGPI H&B) GmbH, Munich
/10/ Specification and description of the software configuration No.: KO12A Digital wide range channel DWK 250 Doc. no.: 023180 B71E Mirion Technologies (MGPI H&B) GmbH, Munich Edition: 1 / 2011-09-08 Page 30 of 30 Doc.No.: 023180 F70E
MGP Instruments GmbH Non-proprietary Version Nuclear Measurement illllMG Munich ALLOCATION - RECORD (during works test procedure)
Reference:
plug in modules and other modules, built in to (Qc*measuring channel -4 ( ) cubicle -4 ( ) equipment --) with designation: jw/f( sLe) acc. to drawing 5 - 3 .3 , edit. _A fabrication no. 054A.0. 214, contract no. 043'8f level:
pos. plug in unit / type of component item part no. / index fabrication no. I remarks Location and date of works test: MUnchen, the /z ,,f. 2'/PI Doc-No. 5 -1L_?,/ L10 Name I Signature of testing person: '-Y.. ,, / . Page 1 of 4 Signature of works inspector (only if required):
Author: MGPI-QM, Gz Releasementof form: Form 0348072 E, edit 5116.04.2002
a M /Ir-/4' Non-proprietary Version MGPO-&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany Certificate of Acceptance Project : Massachusetts Institute of Technology MIT- Nuclear Reactor Laboratory Customer: Mirion Technologies (MGPI), Inc., Smyrna Customer-Order-No.: 0025594 dated: 14.03.2011 Mirion Techn. (MGPI-H&B) This Is a non-proprietary version from which the proprietary order number: 023 180 Information has been removed according to 10 CFR 2.390.
In this document the removed sections of proprietary information are Indicated by two opening and two closing brackets as shown here: (( 11 1 Devices of acceptance :
3
- DWK 250, Digital Wide Range Channel, build in 19" - Rack F-No. 0511.0.216 / 217 / 218 Drawig-no.: 5-8631 G10, G20, G30 and P10, P20, P30 1
- DWK 250, Digital Wide Range Channel in a portable housing F-No. 0511.0.220 Drawig-no.: 5-8630 G21 and P21 4
- TKV 23.11 , Wide Range Preamplifier F-Nr. 0510.0.146 / 150 (Zi =75Q, Zo= 500)
F-Nr. 0510.0.147 / 148 (Zi =500, Zo= 500) 1
- Cable set, ( signal coax cable, HV coax cable, connection between TKV23 Preamplfier and DWK250 for pulse signal, AC-signal, high voltage, control cable)
Diverse mounting material: marking strips, screws, maching plugs, etc.
The devices listed above are incl. documentation completely accepted and without complains.
Munich, date: 14. - 16.12.2011 List of attendants Signature/Stamp MITR, Mr. Edward Lau MITR, Mr. Paul Menadier MITR, Mr. Shawn W. Hanvy Mirion (MGPI) Inc., Mr. Thomas E. O'Malley ...........
Mirion (MGPI-H&B), Mr. Bernhard Held Mirion (MGPI-H&B), Mr. Peter Kandziora This certificate has .10~. pages appendixes.
Cont. Check: MGPI/PK Resp.: Kandziora Form-No. 0348 545 E Formal release. Date: 14.12.2011 Page: 1 of 1
Non-proprietary Version Mirion Technologies (MGPI H&B)
GmbH MGP4,H&B Kernstrahlungsmesstechnik* MUnchen Factory-Acceptance-Test System: Digital Wide Range Channel DWK 250 Project: MIT / USA Mirion-Order-No: 023 180 DWK 250, F-Nr....., 2..
Application: ........... ..1 . ..-..
TYPE OF TEST Factory acceptance test, test protocol : according to this document I TEST DOCUMENTATION Project specific circuit diagram Draw-No.. 5-8630 or 5-8631 G.A./ P.Wf..
Fabrication documentation DWK 250 Doc.-No. 5-0106 12 (2)
User manual DWK 250 Project Doc. No. 5-0106 A70 E 11 Interface Specification DWK 250 K012A 023180 B70E Parameter list DWK 250 K012A 023 180 L71E Short instruction DWK 250/ K012A 5-0106 A50E Technical Information of each unit see also: MGPI-Documentation No.023180 part of the delivery.
further documents TEST EQUIPMENT
))
TEST PROCEDURE Selected components:
Digital channel DWK 250 F-No....A5 Q O. P P4p4
.......e -__.. '..4. . . ....
..-.o.
T KV 2 3 .11 .................... . ......................... F-No.:. .....AW.,A..e
- . o....
F- *..4....Q....... 0
- 1. Visual check:
- Plug in modules according to drawings, completeness, performance, test stamp, etc.
- See also allocation table for the installed units (s. internal test protocol)
- Jumper position, see documentation "Technical Information" of the used plug in units.
ok (...)
- Used firmware:
NZ 12.2x: FW:. -.4_3V... S.'4-Q?7..K0!4e:Y V.P.....
NZ 21.2x: FW.13-f P-0. -i,_91PA7-00%) R.
NK 21.2x: FW:..J4R!e. AC ... 1(2V.A, f ok (..)
Munich . date: . . . f .......... C ustom er .................................
M G PI - te std e p .: ........ .........................................................................................
PPL-No. 5-0106 A21/MIT_023180 E MGPI-Test/PK Date of ed.: 3.12.2011 Page: 1 von 9 DWK_012AMIT_023180.fat
a PNon-proprietary Version Mirion Technologies (MGPI H&B) GmbH Kernstrahlungsmesstechnik. MUnchen
- 2. Preparations / Power supply 2.1 Preparations
- Connect the preamplifier TKV 23 with the channel DWK 250 (Signals, Power supply etc.)
- Don't connect the high voltage at the preamplifier.
2.2 External power supply
- Switch on the power supply. After a few seconds the channel is in operation.
- External supply voltage Uin ok((
supply current li,o =k.
2.3 Internal power supply Measure the voltages at the test jacks of the unit NS 01 and compare it with the specif. values:
specified values : ((
Display value : "internal operating voltage"
((] ok. (4e, )
- 3. Parameter and measurement functions 3.1 Software Identification und checksums:
Software identification.:
DWK 250 3100 519 A K012A e,,-
Checksum: NZ 12.2x: ..... /.. Set value: 15A7 Checksum: NZ 21.2xx: .. 5:6Z.. Set value : 5862 ok 3.2 Release function for parameter- setting
- Lockable switch (NS01,red) set ,OFF" : Not plugged or in horizontal position
-> Parameter-setting is not possible
- Lockable switch (NS01.red) set ,ON": Is plugged and in a vertical position
-> Parameter-setting is possible
-> furthe r sig na lisatio n ....................... . ........................................................
ok.(Lf 3.3 Parameter setting /changing Set all parameter according to the parameter list (s. annex) and record it.
ok.(L4 3.4 High voltage Connect the HV to the amplifier (HV-input).
Take care that there is nothing connected at the detector-input (HV)!
Adjust and measure the high voltage at the output-connector ("U") and in the display of the DWK250:
(Adust it with poti at the NH33-Unit) ((
"U"-jack:
displayed: ok..
Munich date . ............ Customer: ............
MG P I - te stde p :.
.: .......... 0 ............................................................................................
PPL-No. 5-0106 A21/MITm 023180 E MGPI-Test/PK Date of ed.: 3.12.2011 Page: 2 von 9 DWK01 2A MIT 023180.fat
Non-proprietary Version Mirion Technologies (MGPI H&B)
GmbH MGPIH&B Kernstrahlungsmesstechnik ° Munchen
- 4. Functional test and signal processing :
4.1 Preamplifier TKV 23 noise and amplification
((
1]
TKV 23: Preamplifier noise-voltages
((
TKV 23 amplification: Puls- and AC- signal processing Pulse output:
((
11 AC- output:
1]
High AC- amplification: 11.0 V/uA:
((
1]
Munich date: ...... ........ Custom er: ........ ............
MGPI - te std e p .: .......... . ,1 .............................................................................................
PPL-No. 5-0106A21/MIT_023180 E MGPI-Test/PK Date of ed. 3.12.2011 Page: 3 von 9 DWK_012AMIT_023180.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGP4,H&B Kernstrahlungsmesstechnik- Minchen 0 X4I Low AC-amplification ý.lfr V/pA:
[I 11 4.2 AC- Alternate Current Input NA 33 1 Basic setting / correlator gain 11 NA 33 correlator, Basic setting :
1]
ok (....t..)
4.3 Pulse decoupling signal of the NE37 unit I Counter output
))
4.4 Neutron-Flux-Signal processing , Linearity, Signal overlapping Linearity of: Display-measurements, indicators, isolation amplifiers and alarm units
((
I]
M unich , date ....... . . ........ C ustom er: ............................
MG P I - te std e p .: ........... . ..........................................................................................
PPL-No. 5-0106A21/MIT_023180 E MGPI-TestIPK Date of ed.: 3.12.2011 Page: 4 von 9 DWK_012AMIT_023180.fat
a Non-proprietary Version MGP I-IB Mirion Technologies (MGPI H&B) GmbH Kernstrahlungsmesstechnik
- Menchen
((
c0 U)
C:
CO Cn 0
CL Cu CU CO) 0 Q)
EU 1]
Munich. date: *...... 4 , e* ' ....... Custom er: ....... . .. .... ..................
MG P I - tes td e p .: ........... . ...* , ...........................................................................................
PPL-No. 5-0106 A21/MIT_023180 E MGPI-TestIPK Date of ed.: 3.12.2011 Page: 5 von 9 DWK_012AMIT_023180.fat
Mirion Technologies (MGPI H&B) GmbH MGP(&B Non-proprietary Version Kernstrahlungsmesstechnik - MUnchen 4.5 Reactor - Period : Linearity The reactor period is simulated by a log. sweep in the pulse range.
Pulse amplitude must be
- 120 mV.
NFL- Change rate = Ig (fmax Ifmin) *In1O* VAT fm., fmin is a adjustable start-, end-frequency and AT the sweep-time for a genarator (s. table below)
MR: measuring rang = -3.33e-2 ..... 0 ...... +0.1 1/s Measurement readings:
Change rate Display Indicatator isol. amplifier alarms NA06 isol. ampl.
simulated Change rate expect. remarks or given via 0 ..... 20mA binary Periode Change raite value ramp outputs 1Is sec -30....10 sec t......... mA
- i Tolerances: NZ21: 0.2% NZ12: 0.1% NT61: 0.1%
All measurenent values are ok.
- 5. Test-Functions: test generator, simulation-, binary output-, watch-dog-test 5.1 Release-function for the test procedures:
((
1]
5.2 Test generator Preamplifier
((
1]
Munich , date . 6.O..dV.2oP ......... C ustom er: ....... ........................
MG P I - te std e p .: ......... . ... W ...........................................................................................
PPL-No. 5-0106 A21/MIT_023180 E MGPI-TestIPK Date of ed.: 3.12.2011 Page: 6 von 9 DWK_012AMIT_023180.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGPCIH&B Kernstrahlungsmesstechnik - Mbnchen Discriminator Input
((
JJ AC- Signal-Input
((
1] ok.(...4..L.
5.3 Test function : simulation
((
ok.(..t 42]
Munich , date: .......... C ustom er: ......... ...... ..................
MG P I - te std e p .: .......... ....................... I......................................................
PPL-No. 5-0106A21/MIT_023180 E MGPI-Test/PK Date of ed.: 3.12.2011 Page: 7 von 9 DWK_012A_MIT_023180. fat
Mirion Technologies (MGPI H&B) GmbH MGP4,H&B Non-proprietary Version Kernstrahlungsmesstechnik ° Munchen
)) °k'('""A )
5.4 Binary output test El:
1]
5.5 Global Test Status Change the status from "normal" to "test"
-> Binary output NB28 LED- BO1.7 is ,,ON"
-> external signalisation, terminal: .... .. . *# 4.. . ..-. '4 ok.(..C--1.
Signalling is active as long as status "test" is active.
5.6 Watch-dog-test
((
JI M unich date: ....... , . * *(,4 , .. .......... C ustom er: .................................
M G PI - te stde p .: ... 0 0 W, ............................................................................................. :.......
PPL-No. 5-0106 A21/MIT_023180 E MGPI-TestIPK Date of ed.: 3.12.2011 Page: 8 von 9 DWK_012AMIT_023180.fat
Mirion Technologies (MGPI H&B) GmbH MGPO~&B Non-proprietary Version Kernstrahlungsmesstechnik
- Munchen
- 6. Fault message and plug in loop 6.1 Collective Error message 1]
6.2 Plug in loop
- Remove one plug-in unit from the DWK250 (prefer NT-Units)
-- > external signalistion, terminal: ....(I ...... ok.( ..)
- 7. Project specific parameter If known, set project specific parameter values. ok. (... )
- 8. Additional tests :
.... . ..... . ... .............. r e ...... . ............................................
Munich , date : ........ 4 W ' ...... Custom er: ........ ------ ... .......................
MG P I - te std e p .: ......... ....................................................................................
PPL-No. 5-0106A21/MIT_023180 E MGPI-TestIPK Date of ed.: 3.12.2011 Page: 9 von 9 DWK_012A MIT 023180.fat
Non-proprietary Version MGPl-I&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement
- Munich, Germany Parameter list DWK 250 3100 519 A K012A Digital wide range channel Customer: MIT, Cambridge, USA Order - No.: 023180 Detector:
- Default value - - Actual value -
- 1. Plant code: C AI
- 2. Generalsettings:
Discriminator threshold +0.100 Volt 11,,,/ Volt Dead time 0.000e+00 sec Lsec Saturation correction 0.000e+00 sec 41.. .sec AC normalizer 3.000e+09 WNs 1INs Neutron flux calibration factor 1.000e+00 Overlap start ("4) 5.000e+04 1/s 1/s Overlap end / 1.o) 2.000e+05 1Is
- 3. Time constants:
CR_Io [
Tau(CRlo)
CR-hi Tau(CRhi)
Tau(deviation) ]
- 4. Voltage monitoring:
Detector voltage end of range 1000 V L V Detector voltage lower threshold 750 V c" V Detector voltage upper threshold 900 V .. . ..-. V Internal voltage lower threshold 1.850 V t_,/ V Internal voltage upper threshold 2.150 V V..._------V Discriminator voltage lower threshold 0.070 V V Discriminator voltage upper threshold 0.130 V c V Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 MUnchen Fax: +49 (0)89 51513-169 Examin. of contents: sign. BH Author: MGPI-SW, Ter Doc-No. 023180 L71E Formal release: sign. CR Page 1 von 4 Edition 2 / 2011-11-29 Milteilung 5-11310 File: U:edafen\WPdaflprojektkMITOWK_023180_1-11-2011fMITDWKI023180\DWK 250 K012A List of parameteFs 023180 L71E ad2.docx 161 /. '
Non-proprietary Version Digital Wide Range Channel DWK 250 Parameter list for DWK 250 K012A
- Default value - - Actual value -
- 5. Alarms:
Type IoA .'
Measured value Wide range AL 1 Threshold 2.000e+00 cps Hysteresis 50 % f"0 Binary output 8 ;?
Type --- -...... - .... _ _qe Measured value not used .. , , .. .
AL 2 Threshold -- ----------..- /, V, - -- .
Hysteresis --- % ,,, %
Binary output --- 4,,"_
Type --- ---- ,,-'
Measured value not used AL 3 Threshold --- --...
Hysteresis --- % ............... .%.
Binary output -2 Type --- -------------
Measured value not used /. .. M.k._-------
AL4 Threshold --- I.
Hysteresis --- % 1/0 Binary output --- 3 T ype --- ---.-- h ................
Measured value not used ...... eel" I ...........
AL 5 Threshold --- ------------- ." Of Hysteresis --- % 4 Binary output ---
Type --- --------------
Measured value not used ..... "
AL 6 Threshold --- ------------
Hysteresis --- % %
Binary output ---
AL... AL 16: --- (not used) kysrl. W*
80ej/OC Edit: 2PC n. 0 l71e VFd~teon: 2 I2011-11-29 Page 2of 4 Doc. no.: 023180 L71E
Non-proprietary Version Digital Wide Range Channel DWK 250 Parameter list for DWK 250 KO12A
-Default value - - Actual value -
- 6. Analog outputs:
Scaling log Measured value Neutron flux Analog output 1 Start of range %Pn ,"
1.000e-06 End of range 2.000e+02 %Pn Scaling lin Measured value Change rate Analog output 2 Start of range -3.333e-02 1/s End of range 1.000e-01 1/s L_
- 7. Select dimensions:
Raw pulses cps Pulse count cps AC signal normalized cps Wide range signal cps Neutron Flux %Pn Neutron Flux dbl. filtered %Pn Time constant sec L,,/
Page 3 of 4 Doc. no.: 023180 L71E 2 // 2011-11-29 2
Edition: Edition 2011-11-29 Page 3 of 4 Doc.no.: 023180 L71E
Non-proprietary Version Digital Wide Range Channel DWK 250 Parameter list for DWK 250 K012A EPROM - Parameters(NZ21):
- 8. Pulse path:
Time constant Discriminator threshold (start)
Analog output (start of range)
Analog output (end of range) ]
- 9. AC path:
Time constant ((
Locked upper measuring range Locked lower measuring range Measuring range up time-lock Measuring range down time-lock Upper threshold for range switching Lower threshold for range switching
- 10. NZ 21 based alarms:
The three NZ 21 based alarms (Alarm 0, 1 and 2) are not used in this software configuration. They are thus disabled. This is done by setting their threshold levels accordingly.
Mode hiA Measured value KORRSIGGEF Alarm 0 On threshold 64 Volt Off threshold 64 Volt Binary output P3.3 Mode hiA Measured value KORRSIGGEF Alarm 1 On threshold 64 Volt Off threshold 64 Volt Binary output P3.2 Mode hiA Measured value KORRSIGGEF Alarm 2 On threshold 64 Volt Off threshold 64 Volt Binary output P3.5 Note: Alarm 2 is not effective in measuring range #12.
ix - 2 Edition: / 2011-11-29 Page 4 of 4 Doc. no.: 023180 L71E
(( Non-proprietary Version
))
(( Non-proprietary Version 11
Non-proprietary Version MGPI-,&B Mirion Technologies (MGPI H&B) GmbH Nuclear Measurement - Munich, Germany Parameter list DWK 250 3100 519 A K012A Digital wide range channel Customer: MIT, Cambridge, USA Order- No.: 023180 Detector :
- Default value - - Actual value -
- 1. Plant code:
- 2. Generalsettings:
Discriminator threshold +0.100 Volt--------------------- Volt Dead time 0.000e+00 sec C-............... sec Saturation correction 0.000e+00 sec z.. sec AC normalizer 3.000e+09 INs ,. /Vs Neutron flux calibration factor 1.000e+00 Overlap start 5.000e+04 11s L,- 1/s Overlap end 2.000e+05 1/s ( 1/s
- 3. Time constants:
CRIo Tau(CRlo)
CRhi Tau(CRhi)
Tau(deviation) ]
- 4. Voltage monitoring:
Detector voltage end of range 1000 V 6.- V Detector voltage lower threshold 750 V V Detector voltage upper threshold 900 V SJO V Internal voltage lower threshold 1.850 V L,,-- V Internal voltage upper threshold 2.150 V &, V Discriminator voltage lower threshold 0.070 V ,-- V Discriminator voltage upper threshold 0.130 V I V Mirion Technologies Landsberger Str. 328a Tel: +49 (0)89 51513-0 (MGPI H&B) GmbH D - 80687 Munchen Fax: +49 (0)89 51513-169 Examin. of contents: sign. BH Author: MGPI-SW, Ter Doc-No. 023180 L71E Formal release: sign. CR Page 1 von 4 Edition 2 / 2011-11-29 Mitteilung 5-11310 File: U:\daten\WPdallprojekt41IT DWK_023180,..-11.201 1\MIT_DWK_023180\DWK 250 KO12A List of parameters 023180 L71E ed2.docx
Non-proprietary Version Digital Wide Range Channel DWK 250 Parameter list for DWK 250 KO12A
,,,t7#-
/I,,. 7-4 r r - Default value - - Actual value -
- 5. Alarms:
Type oA . .. ._ '
Measured value Wide range .. .. ,.....
AL 1 Threshold 2.000e+00 cps------------------_ . .
Hysteresis 50 % %
Binary output 8 5 Type --- -------------. f.d _ .q Measured value not used .'c-A-AL 2 Threshold --- ------------ X Hysteresis --- % . 4'a Binary output -
Type --- if,I .
Measured value not used _1[ .. ,_
AL 3 Threshold --- --------- Hysteresis --- % .%
Binary output ---
Type ---
Measured value not used . /. .
AL 4 Threshold -. , 2. t-__
Hysteresis --- % "fig %
Binary output ---
Type ------------ If-I ---------------
Measured value not used -------------- -. 49 4. ?? / , Af.
AL 5 Threshold Hysteresis % -------------- _11P -------- %--------
D ; + +
Ial
, y UU IJ u --
Type --- ---------------
Measured value not used AL6 Threshold --- d__<_ .
Hysteresis --- % %
Binary output ---
AL 7... AL 16: --- (not used) wgveasc~weel ralwe p,/ ~e 1A'es/WsU 10,0
/t, 4-. A
- e! 0.14 p(ss 'pa Edition: 2 / 2011-11-29 Page 2 of 4 Doc. no.: 023180 L71E
Al IT-/~
Non-proprietary Version P
MOO.AI BU Mirion Technologies (MGPI H&B) GmbH Kernstrahlungsmesstechnik - M~nchen This is a non-proprietary version from which the proprietary Infonmation has been removed according to 10 CFR 2.390. I In this docurment the removed sections of proprietary 3 Information are Indicated by two opening and two closing brackets as shown here: a B I Cross reference to additional documentation:
On Site Acceptance Test Program Project Neutron Flux I M. I.T.R.
Digital Wide Range Channel DWK 250 DWK 250 Configuration K012A MIT cambrige: Purchase Order 4501352299 date: 03 / 08 / 2011 Mirion Technologies (MGPI) Inc. PO: 0025594 date: 03 / 14 / 2011 Mirion Technologies (MGPI-H&B) Order No: 023 180 date 10 / 05 / 2011 On site acceptance test successfully performed:
Date / Local . , .......... ....
Participants Signature MITR .51.i , *,tY . , .Vy........
PAU'L MpJiNAOJJZ MITR Mirion Technologies Notes:
Examin. of contents: Author: MGPITest, PK Doc-No. MGPI 023180 F31 Formal release: Page 1 von 5 Edition 1 / 20.02.2012
Non-proprietary Version P
MGPOI-IB Mirion Technologies (MGPI H&B) GmbH Kernstrahlungsmesstechnik. MUnchen System : Digital Wide Range Channel DWK 250 (',4 *z &Mt iusuv,,, ,)
Project: MIT Mirion-Xrder-No: 023 180 TYPE OF TEST On site acceptance test, test protocol : According to this test plan PPL-No. 023180 F31 DOCUMENTATION See MGPI-Documentation No.023180 part of the delivery.
Circuit diagram: drawing-no. .f'.. '. 6,... f.2.
TEST EQUIPMENT See used device list in appendix.
TEST PROCEDURE Selected components:
Digital channel DWK 250 (jt/*/a4k c4aLt ) F-N o.: .... O .- '....: 2..2.
Preamp. TKV 23.11 ( in:500 out:500) F-N o. .... . .. .......
Detector WL 23110 S -no.: .... .4. . .0. ..................
- 1. Cabling: inspection and test
)) ok(-')
Futher cables: ...
4... ... t../
,, ',, ./;f A1"*ii4 ,H$ ...........
- 2. Grounding of detector, preamp TKV23 and DWK 250 channel Realized:.
- 3. Eternal / Internal P;ower supply 1]
- External supply voltage Uin = 2@I/ 120 V0 f ok. (4---
- Internal power supply 1: + 5V(+0,1V)
+15 V (+ 0,3 V)
- 15 V (+ 0,3 V)
"internal operating voltage": + 2 V (+/- 0,150 V) ok. (.L.)
1]
Edition 1 / 20.02.2012 Page 2 of 5 Dok. MGPI 023180 F31 DWK_012AMIT_023180_prot.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGPtki&B Kernstrahlungsmesstechnik
- Munchen
- 4. Software Identification Software identification.:
DWK 250 3100 519 A KO12A ok (~
- 5. Parameterameter setting /changing I preparation Set all parameter according to the parameter list Doc.-no. 023180 F31 (in annex)
Set the NA33 cal-pot to" min" (turn left) ok. ('-"K 5.1 High voltage -r +/- 1%/)
(+ 1. dislaed.
displayed: high high vog voltage = ..Nýý..... 4)
Set point =30 V V ecoI// L/
- 6. Functional tests:
6.1 Back ground measurement (without gamma / neutron radiation) : optimizina
[I
)) ok{.(..I Measurement with (low) neutron flux:
((
11 discr. threshold = ...... ....... Pulse count: ................. cps AC-raw signal: ..... V I MR ......
AC sign.normalize ................. cps ok.( ...... )
6.2 Discriminator plateau High voltage = ...... ... V Neutron flux = . .. nv Measurement values (100 .............. cps):
1]
Selected discr. threshold: ...... ... mV -> change the parameter!! ok.*t<)'
Sensitivity (counts / flux) . cps/nv for Udisr. = ..... .-:... mV Diagramm, see appendix.
Edition 1 / 20.02.2012 Page 3 of 5 Dok. MGPI 023180 F31 DWK_012AMIT_023180_prot.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGPO~&B Kernstrahlungsmesstechnik - Munchen 6.3 Adjustment of the AC signal normalized, AC normalization, Overlapping Change the neutron flux and measure the linearity of the pulse rate and the AC signals in the overlapping range 1]
While measuring this values we have to check the overlapping rang (start and end points) and to adapt it, if necessary and also to adjust the AC normalization (factor) to get a acceptable linearity for all ranges.
I]
ok. (.Z*)
6.4 Linearity check and calibration 'e,,. p',"e Finally, a linearity test and the calibration of the Neutron flux value ( ratio: Retr&e8R-i% / wide range signal) should be done if the detector is placed in the final position and operates without any problems. re e. , ok. (.X...)...
- 7. Project specific parameter:
Add. project specific parameter (-> s. parameter list) ok. (.' '..
- 8. Additional tests:
11 Dok. MGPI 023180 F31 Edition 1 /20.02.2012 Page of 55 Page 44 of Dok. MGPI 023180 F31 DWK-01 2A MIT 0231 80_prot.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGP4,H&B Kernstrahlungsmesstechnik - M(nchen Appendix TEST EQUIPMENT Digital m ultim eter, ........... No....R . 9........ . ...............
Oscilloscope .. T . .fr.. i .., . 2..... No... B.A. .9.* . ......................
Signalgenerator ................ .................... No . . .
E ffe ktiv vo ltm e te r . .............. . ................. N o ..................... ....................
..Z**.*./../.,:*...*:*
....8.*#..*.*...*o ¢ ..... ...,....2. .*. ...*.................
Edition 1 /20.02.2012 Page 5 of 5 Dok. MGPI 023180 F31 DWK_012AMIT 023180_prot.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGPII&B Kernstrahlungsmesstechnik - MOnchen Appendix: for SAT protocol Doc. 023180 F31 SAT - Parameter list for DWK Configuration K012A Channel name: pkl#.4 / a F-No....2.
Edition 1 / 16.02.2012 Page 1 of 2 Dok. MGPI 023180 F31 SAT-Parameterlist-fat-DWK 250_MIT-023180
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGP4'PH&B Kernstrahlungsmesstechnik- MOnchen
[f 1]
Edition 1 / 16.02.2012 Page 2 of 2 Dok. MGPI 023180 F31 SAT-Parameterlist-fat-DWK 250_MIT-023180
Non-proprietary Version D,rc ,'.',,ec,pa/o,. /*/&/teW, IVp~c~'
[1 11
Non-proprietary Version
((
1]
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGPC-&B Kernstrahlungsmesstechnik* Minchen System: Digital Wide Range Channel DWK 250 Project: MIT Mirion-Order-No: 023 180 TYPE OF TEST On site acceptance test, test protocol : According to this test plan PPL-No. 023180 F31 DOCUMENTATION See MGPI-Documentation No.023180 part of the delivery.
Circuit diagram: drawing-no. ......... I.. . . . ..
TEST EQUIPMENT See used device list in appendix.
TEST PROCEDURE Selected components:
Digital channel D WK 250 F-No.: P . -4 ,d -tk Preamp. TIKV 23.11 ( in:500 out:50n) F-No. 4:...cmeozm Detector WL 23110 S-no . ..............
- 1. Cabling: inspection and test
((
11 ok Futher cables: Futhe cabls:
.,R.*. .Y..eo.., ,0£* .*...., , a.j....
Y9...I a- e '...
.. *f..u.....*.... ... '..*..,....*...p../..*(..*
' hdLý AA ... /cAk ...
ok(4
- 2. Grounding of detector, preamp TKV23 and DWK 250 channel Realized:
....... [.
ok
- 3. Eternal I Internal Power st 1]
- External supply voltage Uin = pd'/120 Vf ok. (.t*-<)
- Internal power supply NS01: + 5V(+0,1 V) R
"+15 V (0,3 V)
- 15 V (+/-0,3 V)
"internal operating volteige" : + 2 V(0,150 V) ok. (..t*.r' 1]
Edition 1 /20.02.2012 Page,* of W( Dok. MGPI 023180 F31 DWK_012AMIT_023180_prot.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGPI-&B Kernstrahlungsmesstechnik
- Manchen
- 4. Software Identification Software identification.:
DWK 250 3100 519A K012A ok (.L.*f
- 5. Parameterameter setting /changing I preparation ok.(
Set all parameter according to the parameter list Doc.-no. 023180 F31 (in annex)
Set the NA33 cal-pot to " min" (turn left) ok.( ...... )
5.1 High voltage Set point 3,ZV (+/- 1%) displayed: high voltage = ..... ý . .. V ok. (4,e
- 6. Functional tests:
6.1 ((
11 Measurement with (low) neutron flux:
((
discr. threshold = ..... ..... Pulse count: ............-. :. cps AC-raw signal: .......... :,ý . ....V / MR....-
AC sign. normalize:,,7.... ................ cps 6.2 Discriminator plateau High voltage = ...... ..... V Neutron flux = ...... ...... nv Measurement values (100 .............. cps):
1]
Selected discr. threshold: ..... .. *.... mV -> change the parameter !!
Sensitivity (counts / flux): ........ . ...... cps/nv for Udisr. = . . mV Diagfemm, acc appeindix.
Edition 1 / 20.02.2012 Page 2-of O'y Dok. MGPI 023180 F31 DWK0!2AMl'r 023180_prot.fat
a MGPO.,&B Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH Kernstrahlungsmesstechnik
- Munchen 6.3 Adjustment of the AC signal normalized, AC normalization, Overlapping Change the neutron flux and measure the linearity of the pulse rate and the AC signals in the overlapping range
((]
While measuring this values we have to check the overlapping rang (start and end points) and to adapt it, if necessary and also to adjust the AC normalization (factor) to get a acceptable linearity for all ranges.
[I
))
ok.
6.4 Linearity check and calibration :
Finally, a linearity test and the calibration of the Neutron flux value ( ratio: neutron flux / wide range signal) should be done if the detector is placed in the final position and operates without any problems,
((I ok. (.t.
- 7. Project specific parameter':
Add. project specific parameter (-> s. parar,,vtcI,,,,,t
)) ok. (.... )
))
- 8. Additional tests :
11 Edition 1 /20.02.2012 PagejeofT Dok. MGPI 023180 F31 J IV DWK_012AMIT 023180_.prot.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGP-I&B Kernstrahlungsmesstechnik - Munchen Appendix TEST EQUIPMENT Digital multimeter, Bqh ... /*.....'........... No ...... .................
O scilloscope ... /* .. . . . , . . OJ.. No . . '...... ..................
S ig na lg e ne rato r ..................... ................ N o .................... . ......................
E ffe ktiv vo ltm e te r. ..................................... No .............................................
..Z*.r* ..L* .(**.*
./ .. .;. .* .., ?#... .......... ZIP...... ,.. . ..............
Edition 11 16.02.2012 Page Ko*,,, Dok. MGPI 023180 F31 DWK_012AMIT 023180_prot.fat
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGP-II&B Kernstrahlungsmesstechnik* Mi~nchen Appendix: for SAT protocol Doc. 023180 F31 SAT - Parameter list for DWK Configuration K012A Channel name: 72wk/f 5 .......... F-No. .. tL'. ....
((
1]
Edition 1 / 16.02.2012 Page 1 of 2 Dok. MGPI 023180 F31 SAT-Parameterlist-fat-DWK 250_MIT-0231 80
Non-proprietary Version Mirion Technologies (MGPI H&B) GmbH MGPOf&B Kernstrahlungsmesstechnik - M(inchen 11 Edition 1 / 16.02,2012 Page 2 of 2 Dok. MGPI 023180 F31 SAT-Parameterlist-fat-DWK 250_MIT-023180
,41 rr-1 Mirion Technologies (MGPI H&B) GmbH (t MIRION TECHNOLOGIES Landsberger Str. 328a D- 80687 MOnchen Tel. +49 (0)89 51513-0 Fax +49 (0)89 51513-169 Radiation Monitoring Systems Division www.mirion.com MrIon Technologies (MGPI H&B) GmbH
- PF 20 14 23
- D-80014 Mlnchen Munich, 13th November 2013 AFFIDAVIT PURSUANT TO 10 CFR 2.390 AND OTHER GROUNDS I, Roderik Wiedemeier, Managing Director of Mirion Technologies (MGPI H&B) GmbH depose and state as follows:
(1) I am duly authorized by Mirion Technologies (MGPI H&B) GmbH ("Mirion) to execute this affidavit.
(2) I am submitting this affidavit in support of a request to withhold certain information (hereafter "Proprietary Information") from any public disclosure, including without limitation, any request for disclosure under the U.S. Freedom of Information Act, on the grounds that: (A) portions of the Proprietary Information consists of "Controlled Technology" subject to an export control license from the German BAFA which only authorizes its disclosure to the United States Nuclear Regulatory Commission's ("NRC") and the Massachusetts Institute of Technology ("MI") and no other organizations or persons; and (B) portions of the Proprietary Information consists of trade secrets and commercial and financial and/or confidential information of Mirion which can be protected from public disclosure in conformance with the provisions of paragraph (b)(4) of 10 CFR 2.390 of the United States Code. A complete list of the documents containing Proprietary Information is listed in Exhibit A and Mirion is providing two sets of documents, one complete, and one redacted with the Proprietary Information removed.
(3) I have reviewed all of the documents containing Proprietary Information sought to be protected as listed in Exhibit A.
(4) The legal grounds for withholding the Proprietary Information from public disclosure are as listed in Exhibit A.
(5) The Proprietary Information is being disclosed to the NRC and the MIT in confidence and only in connection with an application to qualify certain Mirion products according to the NRC regulations and requirements. Its disclosure outside Mirion is limited to customers, regulatory bodies and others with a legitimate need for the information and is always subject to suitable measures to protect it from unauthorized use or disclosure. It is not available from public sources.
Mirlon Technologies (MGPI H&B) GmbH Reglstergerlcht MOnohen: HRB 136 707 A company of group MIRION Technologies MGP4H&B Gesch.ftf0hrer: Roderik Wiedemeler UST-ID: DE 813 223 535 Bankverblndung: Commerzbank AG, Filisie MOnchen Kontonummer: 221003700 BLZ. 70040041 www.mlrloti.com SWlFT/BIC: COBADEFI700 ISAN: DE29700400410221003700
MIRION TECHNOLOGIES Page 2 (6) In addition, public disclosure of the Proprietary Information is likely to cause substantial harm to the competitive position of Mirion because the Proprietary Information consists of Mirion's technical documents such as equipment manuals, qualification reports, design documents, description of algorithms and certifications all related to the U.S. NRC DWK 250 qualification project. The availability of such Proprietary Information to competitors would enable them to easily modify their products to compete unfairly with Mirion, to take marketing or other actions to improve their product's position or impair the position of Mirion's products. Further, it would enable them to spare important costs developing similar data and analysis in support of their processes, methods or apparatus.
(7) The Proprietary Information has been in the past, and will continue to be, held in confidence by Mirion. It is the type of information customarily held in confidence by any manufacturing company.
Accordingly, Mirion requests that the Proprietary Information be withheld from any public disclosure, and to be notified of any such request for disclosure.
Roderik Wiedemeier Managing Director Mirion Technologies (MGPI H&B) GmbH Vice President Radiation Monitoring System Division MGPi,&B
TMIRION TECHNOLOGIES Page 3 Exhibit A
.a
.2 0 Directory File-Name and document - E
-* C 0 0 0o
- ,-U 5
- =~
0 0 0 X X X X 001 Preamplifier unit 1_01 TKV 23 Technical Information 5-0009 V1 OE ed4 002 General 2 01 TK 250 General protection and safety X -- X X Information instructions 5-0125 AO1E ed2.pdf 2 02 Standard Data TK 250 25438 D09E .. . .. .
ed5.PDF 003 Measuring 3_01 DWK 250 Technical Information 5-0106 X X X X Channel description D22E ed4.pdf 3_02 DWK 350 Short instruction 5-0106 A50E X X X X ed2.pdf 3 03 DWK 250 User Manual 5-8630 A70E X X X X edl.pdf 3_04 Supplement to information in the X X X X operation manual 5-0125 A02E edl .pdf 3 05 DWK 250 K012A Interface specification X X X X 023180 B70E edl.pdf 3 06 DWK 250 K012A List of parameters X X X X 023180 L71E ed2.pdf 307 DWK 250 Computer Interface Manual 5- X X X X T0106 B93E ed2.pdf 004 Electronic 4 01 NA 04 NA 06 Technical Information 5- X X X X Modules 0088 V1OE ed2.pdf 4 02 NA 33.3 Technical Information 5-0292 X X X X V\1OE ed2.pdf 4 03 NB 22 Technical Information 5-0102 X X X X V\1OE ed2.pdf 4 04 NB 28.1 Technical Information 5-0209 X X X X V10E ed3.pdf 4 05 NE 37.21 Technical Information 5-0261 X X X X V-10E edl.pdf 4 06 NH 3x Technical Information 5-0140 X X X X V\10E edl.pdf 4 07 NI 21.2 Technical Information 5-0235 X X X X VF 1E ed3.pdf 4 08 NI 21.21 Modification Description 5-8633 X X X X B50E edl.pdf 4 09 NK 21.2 Technical Information 5-0187 X X X X V\0E ed3.pdf _
4 10 NN 53.21 Technical Information 5-0336 X X X X
_01E edl .pdf I I MGP4tH&B
MIRIO0N M
TECHNOLOGIES Page 4
.2 doE Directory File-Name and document 2E 0-
,0: 5060 w~
o* o o a 0 0 0 0 0I 0
4 11 NR 31 Technical Information 5-0165 X X X X V1OE ed2.pdf 4 12 NS 01 Technical Information 5-0044 X X X X V\1OE ed5.pdf 4 13 NT 61 Technical Information 5-0290 X X X X V\0E ed2.pdf 4 14 NT 61.xx Variant Description 5-0290 X X X X VF19E ed3.pdf 4 15 NZ 12.2 Technical Information 5-0251 X X X X V\0E edl.pdf 4 16 NZ 21.2x Technical information 5-0260 X X X X V\0E edl.pdf 005 Measuring 5 01 DWK 250 circuit diagram 5-8630 G20- X X X X Channels P20 MIT case edl.pdf Arrangement 5 02 DWK 250 circuit diagram 5-8631 G10- X X X X Diagrams P30 MIT cabinet edi .pdf 006 Evidence of 6_01 Evidence of routine test of factory 25015-.. .
routine test 84"B5E ed8.pdf 007 Routine test 7_01 Testrecord routine test for DWK 250 X X X X documentation 0511.0.216.pdf 7 02 Testrecord routine test for DWK 250 X X X X 0511.0.217.pdf 7_03 Testrecord routine test for DWK 250 X X X X 0511.0.218.pdf 7 04 Testrecord routine test for DWK 250 X X X X 0511.0.220.pdf I 008 QA-Certificates 8 01 Mirlon-Technologies KTA 1401 VGB-... .
RWE AHA 02_2010 eng.pdf 8_02 Mirion-Technologies--MGPI-H-B--
GmbHISO9001_en.pdf 009 Typtest 91 01 List of type tested modules 25438 Q10 documentation\ ed2.pdf 901 Common 91 02 Explanation of SW article numbers .. ..
documents 0348573 B11E ed3.pdf 91 03 DWK 250 Functional Specification X X X X 5-0106 D10E ed 2.pdf 009 Typtest 92_01 DWK 250 Certificate No T-01 01_91 .. ..
documentation\ 15.01.1991 - D.pdf 902 General Type 92 02 DWK 250 Certificate No T-0101 91 .. ..
Test of DWK 250 15-01.1991 - E~pdf 92 03 Test program for the global test of the X X X X DWVK 250 - 17.12.1990 - E.pdf I I I MGP(jH&B
HMIRION TECHNOLOGIES Page 5
- =
1.0 250.2 1 199 O.pd Directory 2.20 File-Name 1 and documentao E 0 v 0df o
Lo U. 0 o.. 2 0 0 ~0 U
9204 Test results of the global test of the X X X X DWVK 250 February 1991.pdf 92_05 Technical test report for the DWK 250 X X X X Jufy 1991 -E.pdf 009 Typtest 93_01 Technical test report for the SW of the x X X X documentation\ DWK 250 Aug. 1990 - E.pdf 93_03 Type test certificate for the SW of the DWI< 250 No 1225068496_01 Aug. 1990 -
E.pdf 93 04 TUV Certificate for DWK 250 K0005 .. .. . .
Doc.-No. 27-97-YQ-A01 E.pdf 009 Typtest 94_01 DWK 250 K012A Configuration X X X X documentation\ specification 023180 B71 E ed 1 - E.pdf 904 Software Cofi uato 94_02 02D DWKK20 250 K K011AItraeseiiain 2A Interface specification x X- - X Configuration 023180 B7OE edl - E.pdf 94 03 DWK 250 KO12A List of parameters X - X X 023180 L71E ed2 - E.pdf 94_04 DWK 250 K012A Verification plan and X X X X protocol 023180 F70E ed 1 - E.pdf 94 05 DWK 250 K012A Verification plan and pr6tocol 023180 F70E edl - Template - E.pdf 009 Typtest 9501 Quality assurance in the Software documentation\ Development - Manual - 0348548E - edl .pdf X -- X X 905 SW QA 95 02 Software Quality Assurance Plan Documents (SOAP) - 0348664 A60E - ed4.pdf X - X X 9503 Software Verification and Validation Plan -.
(SVVP) - 0348666 A60E - ed2.pdf X _-- X X 95_04 Software Configuration Management X - X X Plan (SCMP) 0348665 A60E - ed2.pdf 95_05 Software Coding Rules 0348662 A60E - X -- X ed2.pdf 009 Typtest 961_01 NB 28.1 NT 31.1 NS 01.12 NK 21.2 documentation\ PrOfzeugnis.pdf .. .. .. ..
906 Processor 961 02 NZ 12.11 NK21.2 NB 28.1 NT31.1 NS X X X X boards\ 01.F2 Praktische Typprffung.pdf 01 NK 21.2 961 03 NZ 12.11 NK 21.2 Stellungnahme zu X X X X den Anderungen 945-K 73001-95.pdf 961_04 NK 21 Test Certificate TUV Rheinland -. .. .. .. .
I E.pdf I II MGP(*I&B
MIRION TECHNOLOGIES Page 6 Directory File-Name and document 'u
- c.- E 0° 0 u gCIQ 0 0 U U05 009 Typtest 962 01 NZ 12.21 Technischer Prefbericht X X X X documentation\ Februar 2008.pdf 906 Processor 962 02 NZ 12.21 Certificate Nr. - .. . .
boards\
o2NZ 12.21 ETS1 NZ12.21 1 Februar2008.pdf 962_03 NZ 12.21 Technischer Pr~fbericht Nr. X X X X NZ 1221 082008 Februar 2008.pdf 962_04 NZ 12.21 Theoretische Pr0fung.pdf X X X X 962_05 NZ 12.21 Grenzbelastungsanalyse.pdf X X X X 962 06 NZ 12.21 PrOfanweisung Praktische X X X X Prbifng.pdf 962_07 NZ 12.21 Praktische Pr0fung.pdf X x x X 009 Typtest 963A 01 Zertifikat NO TK250 Baugruppen .. . . .
documentation\ 042007 Anhang l.pdf 906 Processor 963A 02 TK 250 Baugruppen Technischer X X X X boards\ P 03 NZ 21.21\ Pr~fbericht.pdf A NO TK250 963A 03 TK 250 Baugruppen PrOfprotokolle X X X X Baugruppen 042007 Anhang 2.pdf 009 Typtest 963801 NZ 21.21 NZ 21.22 Technischer X X X X documentation\ PrOfbericht KTA 3505.pdf 906 Processor 963B 02 NZ 21.21 NZ 21.22 Certificate Nr. --
boards\ N 03 NZ 21.21\ NZ21.21_22062O(6.pdf B_NZ21.2122 963B 03 NZ 21.21 NZ 21.22 Technischer X X X x 062006 PrOfbericht Protokolle Anhang 2.pdf 010 FAT 10_01 Certificate of Acceptance with X X X documentation: attachments 14-16.12.2011 .pdf 011 SAT 11_01 MIT SAT Protocol No. 023180 Date 25- X X X documentation 02-2012.pdf MGPIH&B
~MIRION TECHNOLOGIES Page 7 00 1 0 Directory File-Name and documentSytm ,
ooo C su o o~t o CL
~ 5 iia Upgrade ~ Sse ~ ~-oW witnb ~ V.- 0 C Mr.
MITOctobe EdLau 2013 frm a 0 0 0 By E-Mail 'Write-up document" Nuclear Safety System X x x X Upgrade - DWK 250 Digital System (written by Mr. Ed Lau from MIT October 2013)
- Complete un-blacked version
- Redacted version (controlled parts blacked)
- Document which contains the summary of the controlled technology
- End -
MGPH&B