ML20134F035

Discusses 960916-18 Audit of Dynamic Controls Hamilton Standard Oscillation Power Range Monitor.Two Discrepancies Identified & Must Be Corrected Before Oscillation Power Range Monitor Can Be Connected.Rept Encl

ML20134F035
Person / Time
Issue date:	10/30/1996
From:	Matthews D NRC (Affiliation Not Assigned)
To:	Donovan K CENTERIOR ENERGY
References
PROJECT-691 NUDOCS 9611040232
Download: ML20134F035 (12)

Text

'

I October 30, 1996 l ' t.

l Mr. Kevin P. Donovan, Chairman l Boiling Water Reactor Owners' Group Centerior Energy Perry Power Plant MC A210 P. O. Box 97 1 Perry, OH 44081

SUBJECT:

SOFTWARE AUDIT OF THE DYNAMIC CONTROLS HAMILTON STANDARD OSCILLATION POWER RANGE MONITOR l

Dear Mr. Donovan:

On September 16, 17, and 18, 1996, the staff conducted an audit of the Dynamic Controls Hamilton Standard oscillation power range monitor developed by ABB-CE for the BWR Owners' Group at the Dynamic Controls offices in Windsor, CT. A report of this audit is attached. Two discrepancies were identified: (1) the requirements traceability matrix did not contain all of the software life cycle phases, and (2) the documentation indicates that the verification activities were not acceptable. These deficiencies are identified as open items in the audit report and must be corrected before the oscillation power range monitor can be connected to the reactor trip system. A follow-up audit is scheduled for later this year.

l l If you have any questions concerning this audit report, please contact the project manager, Jim Wilson, at (301) 415-1108.

Sincerely, DavidY.MatEews,#' Chief l Generic Issues and Environmental i Projects Branch l Division of Reactor Program Management l Office of Nuclear Reactor Regulation l

Project No. 691 l cc: see attached list DISTRIBUTION:

Central File OGC DMatthews PUBLIC ACRS RArchitzel

! PGEB r/f JWermiel MWaterman l

TMartin JMauck BBoger f

Document Name:BWRAUDIT.I&C C//

OTC PGEB M M SC:PGEB/YkC:liICB , C:PGENh il

'I NAME JWilsodw' RArchitzb JWeN1 DMatthews DATE 10/4/96 10/71/96 10/Zf/96 /

10[3096 0FFICIAL RECORD COPY l l6y 10 g 2 961030 691 PDR

$ gg b i C )

@O7  !

. _ _ . _ _ .- __ _ _ _ _ ._ _ = _ _ ._ _ _

l >*%q l g UNITED STATES

!' [  % NUCLEAR REGULATORY COMMISSION E

f WASHINGTON, D.C. 20065-0001

.....* October 30, 1996 i

1 Mr. Kevin P. Donovan, Chairman Boiling Water Reactor Owners' Group Centerior Energy

, Perry Power Plant l MC A210 P. O. Box 97 Perry, OH 44081 ,

SUBJECT:

SOFTWARE AUDIT OF THE DYNAMIC CONTROLS HAMILTON STANDARD OSCILLATION POWER RANGE MONITOR l

Dear Mr. Donovan:

On September 16, 17, and 18, 1996, the si.aff conducted an audit of the Dynamic Controls Hamilton Standard oscillation power range monitor developed by ABB-CE i

for the BWR Owners' Group at the Dynamic Controls offices in Windsor, CT. A report of this audit is attached. Two discrepancies were identified: (1) the j requirements traceability matrix did not contain all of the software life cycle phases, and (2) the documentation indicates that the verification

" activities were not acceptable. These deficiencies are identified as open items in the audit report and must be corrected before the oscillation power range monitor is connected to the reactor trip system. A follow-up audit is scheduled for later this year.

l i

If you have any questions concerning this audit report, please contact the project manager, Jim Wilson, at (301) 415-1108.

l Sincerely, David B. Matthews, Chief l.

Generic Issues and Environmental Projects Branch Division of Reactor Program Management Office of Nuclear Reactor Regulation l

Project No. 691 cc: see attached list 4

~,

Boiling Water Reactor Owners Group l

cc: C. D. Terry Vice President, Nuclear Engineering Niagara Mohawk Power Corporation i

Nine Mile Point-2 '

PO Box 63 I Lycoming, NY 13093 D. B. Fetters PECO Energy Nuclear Group Headquarters HC 62C-3 l 965 Chesterbrook Blvd.

l Wayne, PA 19087 R. A. Pinelli l GPU Nuclear l MCC Building E l One Upper Pond Road Parsippany, NJ 07054

! S. J. Stark l GE Nuclear Energy l 175 Curtner Ave, M/C 165 j San Jose, CA 95125 T. J. Rausch

Commonwealth Edison Company i Nuclear Fuel Services l 1400 Opus Place, 4th Floor ETWIII

! Downers Grove, IL 60515 D. B. Bockstanz l

Pennsylvania Power and Light Co.

Two North 9th St.

Allentown, PA 18101-1179 l

1 4

SOFTWARE AUDIT OF THE DYNAMIC CONTROLS HANILTON STANDARD (DCHS)/ABB-CE OSCILLATION POWER RANGE MONITOR (0PRM)

1.0 INTRODUCTION

The BWR Owners' Group contracted ABB-CE to develop an OPRM system for use in BWR plants to detect and suppress reactor power oscillations, as required by GDC 12. ABB-CE contracted Dynamic Controls Hamilton Standard (DCHS) to develop the hardware and software, and assumed the role as the independent i verification and validation (IV&V) organization. l To ensure the OPRM system conforms to 10CFR50 Appendix B criteria for quality, NRC staff conducted an audit of the OPRM system development. Mike Waterman, the NRC auditor, conducted the entrance meeting on 9/16; and summarized the audit results at the exit meeting on 9/18.

2.0 EVALUATION The Period Based Algorithm (PBA) system requirement was selected for the software thread audit because this requirement is used in the licensing bases for the plants. As such, the PBA represents a critical requirement that must meet 10CFR50 Appendix B requirements.

2.1 Descriotion of the PBA Function The PBA detects peaks and valleys in neutron flux signal levels from selected groups (cells) of local power r oge monitors (LPRMs). When a sufficient number of consecutive neutron flux oscillations occur (Cell Confirmation Count) within the frequency range that characterizes the onset of unstable reactor power fluctuations, the PBA provides alarm and trip signals to the RPS. A peak is defined as an increase in the neutron flux level followed by one decreasing sample. A valley is defined as a decrease in the neutron flux level followed by one increasing sample.

For each detected peak or valley, the confirmation count value will be cleared if the peak with valley is outside the area of interest, or the count will be incremented if it is inside the area of interest. Consecutive confirmation counts of peaks with valleys that occur within the required time limits (Tmin and Taax) are compared to an alarm setpoint (NI) and a trip setpoint (N2). 1 Exceeding the alarm setpoint for confirmation counts results in an alarm signal for the operator. If the neutron flux oscillation normalized amplitude or the peak value exceeds the setpoint (Sp), and the number of consecutive confirmation counts exceeds the trip setpoint (N2), the reactor is tripped.

The amount of required increase or decrease necessary to result in an-indication of a peak or valley is the noise floor. Because each plant has its own characteristic noise levels, and these levels may change over time as 1 LPRMs age, the noise floor value is an input variable value (MT_ Noise _ Floor)

entered by the operator.

i

~.

2.2 Audit Results The thread audit followed the evolution of the PBA requirement from the ABB-CE system requirements document (Ref. 1) through the DCHS Software Requirements Specification (SRS, Ref.-2), the DCHS Software Design Description (SDD, Ref. 3), the source code (Ref. 4), to the DCHS factory acceptance test plan, procedure, and report (FAT, Refs. 5, 6, and 7). Supporting documents describing project management requirements were also referenced (e.g., the Software Development Plan, Ref 8, the Software Configuration Management Plan, Ref. 9, and the AB8-CE Requirements Traceability Matrix (RTM), Ref. 10). The software lifecycle is comparable to the waterfall lifecycle described in i IEEE Std 7-4.3.2-1982, as endorsed by RG 1.152 (1985). DCHS developed the l software using the Ada 83 programming language. The software was compiled on a DACS VAX/VMS for an Intel 80186 microprocessor, using a Bare Ada Cross Compiler, Release 4.6.2. The Computer Software Unit (CSU) number group for the set of subprograms comprising the PBA was 3400. l The PBA functional requirement was found in the OPRM Module SRS (13.1.23); the i OPRM SDD (13.2.4.3, 14.4.3.1, and the bubble diagram in 13.2.4); the source i code listing (CSU 3410) and the Test / Validation Test of MT-Noise-Floor (1C3.1.23.1-3, TM1-2.1.14). The staff verified that the requirement is l correctly stated in the applicable documents. The staff noted that the Requirements Traceability Matrix (RTM), which was maintained by the ABB-CE 1 Independent Verification and Validation (IV&V) team, does not include the Computer Program Code Listing (Implementation Phase). ABB-CE was requested to provide inforration regarding the IV&V of this phase of the software i lifecycle. This documentation will be provided at a later date. This is an I open item.

i Tables 1 and 2 list PBA input and output variables, as described in the System Spec, SRS, SDD, and source code listing. Table 3 provides definitions and comments for the input variables listed in SDD Volume 1.

As shown in Table 1, the input variables were not consistent between the lifecycle phase documents. For example, LTSSS Time, which is used to define Cell (c).Tpeak, Cell (c). Previous Peak, Cell (c).Tva11ey, and Cell (c) Previous Valley, and is,_used as the clock for comparison with Tain and Tmax, wis not liited as an input variable requirement prior to SDD Volume 1, although this variable is included as a requirement in SDD Volume 2. Since LTSSS Time was added to Volume 2, it should also have been added to Volume 1, and tKe documentation of previous lifecycle phases. Another example is the input variable, DR3, which is listed as a required input variable only in the System Specification and SDD Volume 1. As described in Table 3, DR3 is

required only in the Amplitude and Growth Rate algorithms, not in the PBA.

1 These major discrepancies in the documentation led the staff to conclude that the V&V and IV&V efforts did not sufficiently verify the lifecycle phase i products for the input variable requirements. The staff requested that DCHS 4

and ABB-CE complete the verification of the PBA function and correct these

discrepancies in the input variable requirements. This is an open item.

t j

The staff noted that the PBA functional requirements and the output variable requirements were consistent throughout the lifecycle phases. Based upon its review of the software code listings and the factory acceptance test (FAT) results, the staff verified that the discrepancies between the input variable lists of the lifecycle phase documents were not carried over into the PBA pseudocode description, and did not affect the number or type of the output variables.

Output variables are generally defined by the pseudocode for each requirement, l

and should not change unless the pseudocode is also changed. Since the PBA logic remained unchanged throughout the lifecycle phases, while the documentation describing the input variable requirements did change, the staff concluded that verification effort may have concentrated on ensuring consistent pseudocode descriptions throughout the lifecycle. Less effort is evident for the supporting documentation of the pseudocode.

As shown in Table 2, the output variable names remained essentially unchanged throughout the lifecycle from System Requirements through the Implementation phase. Inspection of the source code listing revealed three additional output variables that were not described in the SDD (Cell (c). Detecting Peak, Cell (c). Previous Peak, and Cell (c). Previous Valley). These three variables were defined in The source code, and are output variables only by virtue of being defined in the variable type, Cell. Their inclusion in the source code for the PBA does not affect the PBA function, and are therefore acceptable.

The staff reviewed the Factory Acceptance Test (FAT) Plan (Ref. 5), FAT Procedure (Ref. 6), and FAT Report (Ref. 7). The purpose of the review was to verify the PBA tests acceptably address all the PBA requirements.

The FAT Plan (Ref. 5) objectives were to define the following:

1. Activities required for preparation and conduct of the FAT

2. The tasks to be performed and the schedule to be followed

3. Sources of information used to prepare the FAT plan

4. Test tools and the environment needed to conduct the FAT.

The scope of the FAT Plan was to ensure testing of all requirements imposed by SRS 0320-01. Testing includes simulating all OPRM inputs simultaneously. The test input signals simulated typical reactor core regional and core-wide oscillations and normal noise conditions. ABB provided the test data input signals, which were obtained from the BWROG and verified prior to delivery to i the system developer. The tests were designed to validate requirements for detecting instabilities and not causing spurious trips.

l The FAT Plan (Ref. 5) is acceptable. The PBA was test feature 'v' in the FAT l Pl an. The staff attended the FAT and verified that conduct of the testing conformed to the FAT Plan requirements.

_4_

l  :

The staff reviewed the FAT Procedure (Ref. 6). The main body of the FAT Procedure provides general test information, including test definition, and assumptions and constraints considered in the test development process. The remainder of the FAT Procedure concists of appendices describing the test setup and equipment, the procedures for creating the standard setpoint and configuration files for the two OPRM units in the test setup, the step-by-step test procedures with test inputs and expected results, additional testing requirements necessary to complete Maintenance Terminal (MT) software functional verification, analog waveform descriptions and procedures for recreating each waveform, and the FAT Test Data Log Sheets necessary for the OPRM FAT.

The staff reviewed the PBA test paragraph, C3.1.23, 00A Period Based Algorithm. The System Requirement states that the PBA will generate a trip output when a periodic oscillation occurs in any LPRM cell with a period between Tmin and Tmax, a cell peak greater than Sp, and a duration equal to or greater than N2. An alarm is generated when the duration of the oscillation is greater than or equal to N1, regardless of the oscillation amplitude in relation to Sp. These values are set with the maintenance terminal (MT); the resulting counting and trip status are reported on the MT and transmitted to the personal computer (PC) workstation that was set up to monitor the test results. The staff reviewed the input data and the test coverage and found the procedure to be acceptable.

The staff reviewed the PBA test results (Ref. 7) and witnessed the FAT initiated on August 2, 1996, and completed on August 6, 1996. One Failure Report was created (FR 111084) during the PBA testing when the setpoint and configuration files were not reset to 000 prior to the test initiation. The files were corrected and the tests were successfully completed. The test results validated correct implementation of the FJA requirements.

The FAT documentation states that the FAT was conducted to verify compliance with the LTSSS Requirements Specification (Ref. 1) and the OPRM SRS (Ref. 2).

As noted in this report, the documentation is not consistent throughout the lifecycle phases with respect to input variable requirements. Based on the discrepancies concerning the input variables listed in the documentation, which changed between the System Requirements phase and the Implementation (Source Code) phase, the staff concluded that tests to validate the system requirements and the software requirements may have been written based on the algorithm requirement, and not on the listed input variable requirements. The staff noted that the test requirements acceptably addressed the functional requirements of the PBA; regardless of the errors in the input variable documentation. Consequently, the validation tests were acceptable.

3.0 CONCLUSION

S The staff reviewed the PBA function in the LTSSS OPRM developed by DCHS and ABB-CE for the BWROG. The staff found input variable requirement i inconsistencies within and between the documentation for the lifecycle phases.

However, the output variable requirements remained consistent throughout the

lifecycle, as did the algorithms for detecting and initiating an alarm and

{ trip signal. The staff concluded that the backward traceability of the source code to the system requirements was not maintained. There is no immediate safety impact from this deficiency; however, revisions to the PBA, which also

a i

i  :

i j must conform to Appendix B criteria for safety-related systems, will become increasingly more difficult without a fully ~ consistent set of documentation i

l for the entire lifecycle.

Based on inconsistencies in the documentation, the staff concluded that the  !

q software verification activities were not acceptably implemented with regard l to revising the supporting life cycle documentation. Consequently, over the '.

lifetime of the OPRM system, revisions may become correspondingly more difficult to correctly implement because incomplete documentation describing  ;

the system will- be the only source of information regarding the structure of j

the code.  ;

i 1

The ABB/DCHS OPRM system will be installed in Clinton, Cooper, Dresden 1 and  !

2, Hope Creek, La Salle 1 and 2, Quad Cities 1 and 2, and Susquehanna 1 and 2.

i As stated in the approved Topical Report (Ref.12), each plant will monitor

the performance of the OPRM for one fuel cycle before connecting the OPRM

, system trip output relays to the Reactor Protection System. Based on 1

successful completion of the FAT, which was witnessed by the staff, the OPRM I i system may be installed in nuclear power plants in this system test )

l configuration. '

! However, as stated by the staff in the Exit Meeting on 9/18/96, since Appendix

! B to 10CFR50 requires acceptable quality in both documentation and product,

! the OPRM software lifecycle verification must be completed and the i documentation corrected, reviewed by the staff, and approved prior to final i staff approval of the OPRM system as a safety-related component of the Reactor 1 i Protection System. None of the plants has installed the system for their

current fuel cycle. Consequently, ABB and DCHS have at least one fuel cycle i

(approximately 24 months) to correct the existing documentation and receive

! final NRC staff approval. Additionally, ABB-CE must provide the staff with j the IV&V results for the source code development phase of the software i lifecycle. These two items will remain open pending final staff review and j acceptance.

4.0 REFERENCES

1 i

1. "LTS Stability System Design Service Project for the Boiling Water Reactor Owners Group of Participating Utilities, LTSSS Requirements Specification," 00000-ICE-3230 Rev 3, ABB-CE, dated 5/29/96

2. " Software Requirements Specification for the Long Term Solution Stability System Module (LTSSS)," SRS 0320-01, Rev C, Data Item 005A, DCHS, dated 9/10/96

3. " Software Design Description for the Long Term Solution Stability System Module (LTSSS)," SDD 0320-01.02, Rev B, Data Item 006A, (Volumes 1 and a 2), Preliminary (final version not through the ABB-CE review process), i DCHS i

4. " Computer Program Listing for the Long Ters Solution Stability System )

(LTSSS)," Data Item No. 017A, CPL 0320-01.02, Rev A, DCHS, dated 8/14/96 l

5. " Factory Acceptance Test Plan (FAT) for the Oscillation Power Range i Monitor (0PRM)," Data Item 013, R1471, Rev B, DCHS, dated 5/25/95 I

6. " Factory Acceptance Test Procedure for the Long Term Solution Stability System (LTSSS) Oscillation Power Range Monitor (OPRM) Module, PN 11426-1,-2", Data Item 014A, R1495, Rev B, DCHS, 8/5/96

7. " Factory Acceptance Test Report for the Long Term Solution Stability System (LTSSS) Oscillation Power Range Monitor (0PRM)", Data Item 015A, R1618 Rev A, DCHS, 8/28/96

8. " Software Development Plan for the Long Term Solution Stability System Module (LTSSS)," SDP 0320-01, Rev D, Data Item 007, DCHS, dated 8/15/96 i 9. "LTS Stability System Design Service Project for the Boiling Water

l. Reactor Owners Group of Participating Utilities, Software Configuration l Management Plan," 00000-ICE-15143, Rev 01, ABB-CE, dated 8/3/94

10. ABB Requirements Traceability Matrix

11. "Long Term Stability Solution System Project Plan," R1452, Rev B, Data Item 002A, DCHS, dated 10/21/94

12. " Generic topical Report for the ABB Option III Oscillation Power Range Monitor (0PRM)," CENPD-400-P-A, Rev 01, ABB-CE, May 1995.

13. "Self Test Requirements for the Oscillation Power Range Monitor (0PRM),"

DCC PN 11426-1/-2, Data Item 005A, DCC1713, dated 5/5/95

14. " Software Programmers Manual for the Long Term Solution Stability System Module (LTSSS)," Data Item 112A, SPM 0320-01, Rev B, DCHS, dated 8/26/96 l

15. " Computer Resources Integrated Support Document for the Long Term Solution Stability System Module (LTSSS)," Data Item 008, CRISD 0320-01, Rev B, DCHS, dated 9/4/96 l 16. " Interface Design Document for the Long Term Solution Stability System Module (LTSSS)," IDO 0320-01, Rev B, DCHS, dated 8/27/96

17. " Version Description Document for the Long Term Solution Stability System Module (LTSSS)," VD0 0320-01.02, Rev B, Data Item 111A, DCHS, dated 8/15/96

18. Problem Tracking Forms, DCHS i

h

,+ w -

~r,

• _. . ___ .m._ _ ..__ _ __ _ . _ _ . . _ _ -. _ . . _ _ _. _ _ _ _ _ _ __

Tt bla 1. Pcriod-Based Alg::rithm input Vcriables System Specification SRS SDD Volume 1 SDD Volume 2 Source Code Listing Cell _ Range Algorithm _lnitializing Cell (c). Detecting _ Peak Cell (c). Detecting _ Peak Cell (c).First_ Peak _Found Cell _ Norm _ Amplitude [cl Cell _ Norm _Amplitudelcl Cell (c). Norm _ Amplitude Cell (c). Norm _ Amplitude Cell (c). Norm _ Amplitude Cell (c). Previous _ Peak Cell (c). Previous _ Peak Cell (c) Previous _ Valley

_ Cell (c) Previous _ Valley Cell (c).Tbase_ Established Cell (c).Tbase (Undefined)

LTSSS_ Time LTSSS_ Time DR3 DR3 MT_ Noise _ Floor MT_ Noise _ Floor MT_ Noise _ Floor N1 N1 NI N1 N2 N2 N2 N2 Sp Sp Sp Sp Tm:x Tmax Tmax Tmax Tmax Tmin Tmin Tmin Tmin Tmin TOL TOL TOL TOL TOL

Tabla 2. Period-Bas:d Algorithm Output Varirbits i System Specification SRS SDD Volume 1 SDD Volume 2 Source Code Listing  ;

Ccil_ Confirmation _Countic) Cell _ Confirmation _Countici Cell (c). Confirmation _ Count Cell (c). Confirmation _ Count Cell (c). Confirmation Count -

Cell (c). Detecting _ Peak Cell (c). Detecting _ Peak Cell _ Peak lcl  !

Cell _Peakic] Cell (c). Peak Cell (c). Peak '

Cell (c). Peak Cell (c). Previous _ Peak Cell (c). Previous Peak Cell (c). Previous _ Valley Cell (c). Previous _ Valley l Cell _ Period _ Alarm (c) Cell _ Period _Alarmic] Cell (c). Period _ Alarm Cell (c) Status. Period _ Alarm Cell (c) Status. Period _ Alarm Cell _ Periodic] Cell _ Period [cl Cell (c). Period Trip Cell (c). Status. Period _ Trip Cell (c). Status. Period _ Trip Cell _Thaselc] Cell _Tbase[cl Cell (c).Tbase Cell (c).Tbase Cell (c).Tbase Ccil_Tpeakici Cell _Tpeak[cl Cell (c).Tpeak Cell (c).Tpeak Cell (c).Tpeak Cell _Twalley[cl Cell Tvalleylci Cell (c).Tvalley Cell (c).Tvalley Cell (c).Tvalley Ccil Vrileylci Cell _Valleylc] Cell (c). Valley Cell (c). Valley Cell (c). Valley I Table 3. Period-Based Algorithm input Variable Definitions Vtritble Name Type Description Notes  !

References Algorithm-initializi Flag Flag used to indicate completion of Not an input variable in SRS 3.1.23.2 (ODA Priod ng RO2 Item 45 initialization Based Algorithm inputs) SRS 3.1.15 Not included in SRS Table 1, LTSSS Variable List SDD  !

Listed as an input in SDD 3.2.1.1.2 3.2.1.1, i Defined via Set in SDD 3.2.1.1.3 (Initialization and 3.2.4.5.1, i Executive Processing) 4.1, and '

Defined in SDD 4.2.1.2.3 (MAIN Logic Flow - CSU 4.1.2 No.1002)

Cell (c).First_ Peak _  ? Not defined in the SRS 3.1.23, not included in the Found pg 49 LTSSS Variable Lists  !

Cell (c). Norm _ Amp Analog Cell amplitude after filtering and shown as Cell _ Norm _Amplitudelcl in DCHS SRS and litude normalization by the DC value ABB LTSSS Resquirements Spec, shown as i Cell (c). Norm _ Amplitude in the SDD,

. - - - . _ . - . ~ - . - - - ~ . - - - - . - - - . - - . . . - . - . .

i Tsble 3. Pcriod-Based Algorithm input Vari 1bl2 Definitiona ,

t Vcriable Name Type Description Notes References  !

Cell (c).These_ 7 Not defined in the LTSSS Variable Lists. Not used in Estrblished SDD Volume 1. May be Cell (c).Tbase DR3 Integer Growth rate factor SP for Amplitude Shown as an input to the PBA in the ABB LTSSS and Growth Rate algorithms Requirements Spec 3.1.23.2, SDD 3.2.4.3.2, not shown as an input in SRS 3.1.23.2 i

MT_ Noise _ Floor Analog A representation 6f the lowest Not an input in ABB Req. Spec DCC SRS, shown as an ABB Req detectable change at the analog input input in DCHS SDD. 3.1.23, termmals. Used to verify detetion of SRS 3.1.23, peaks and valleys in ODA Cell value. SDD 3.2.4.3 May be a function of APRM Power or Cell average value.

i N1 Integer Period confirmation alarm SP Not an input in LTSSS Req Spec; shown as an input in SRS 3.1.23 and SDD 3.2.4.3. However, N1 used in i LTSSS pseudo code N2 Integer Penod confirmation trip SP Not an input in LTSSS Req Spec: shown as an input in '

SRS 3.1.23 and SDD 3.2.4.3. However, N2 used in LTSSS pseudo code Sp Analog - Priod based trip amplitude Not an input in LTSSS Req Spec: shown as an input in SRS 3.1.23 and SDD 3.2.4.3. However, Sp used in LTSSS pseudo code Tmax Time Maximum oscillation period Tmin Time Minimum oscillation period TOL Analog Period tolerance

- - _ _ _ _ _ = _ _ _ . _ _ _ _ _ _ _ _ _ _ - . - - _ - _ _ _ _ _ _ _ _ _ _ _ _ _ - -_