System Engineering Handbook R91 - 1

SYSTEM ENGINEERING HANDBOOK
73TD-0ZZ03
Revision 9.0
_____________________________________________________________ Reason for Revision Added information in Appendix D, Walkdown Standards regarding inspection criteria for tritium monitoring by engineering walkdowns in accordance with NEI 07-07 as specified by CRAI 3304266. ______________________________________________________________ Introduction This Technical Document conveys good work practices, general standards and performance expectations regarding conduct of System Engineering activities at PVNGS. This guidance is not intended to supersede existing Company policies, procedures, or directives. ______________________________________________________________
Glover, John J (Z30799) _________________________________________

Technical Approval
Digitally signed by Glover, John J(Z30799) DN: cn=Glover, John J (Z30799) Reason: I have reviewed this document Date: 2009.05.11 12:16:06 -07'00' ___________________
Date
_________________________________________ Owner Approval
Sweeney, Kevin M (Z99575)
Digitally signed by Sweeney, Kevin M(Z99575) DN: cn=Sweeney, Kevin M (Z99575) Reason: I am approving this document Date: 2009.05.11 16:50:29 -07'00'
____________________ Date
Technical Document
Page 1 of 42
73TD-0ZZ03
Revision 9.0
TABLE OF CONTENTS
1 2 3 4 5 6 7 8 9 10
INTRODUCTION...............................................................................................................3 MISSION STATEMENT ...................................................................................................3 SYSTEM ENGINEERING ROLES AND RESPONSIBILITIES..................................3 PERFORMANCE MONITORING AND TRENDING ..................................................5 MAINTENANCE RULE..................................................................................................11 WORK MANAGEMENT ................................................................................................13 SYSTEM HEALTH REPORT ........................................................................................15 TESTING...........................................................................................................................15 MARGIN MANAGEMENT ............................................................................................16 TRAINING AND QUALIFICATION OF SYSTEM ENGINEERS.............................18
Appendices A B C D E System Health Report Guidance PVNGS System Engineering - System Work Assignment Authorization Systems Requirements - Trending, Health Reports and Walkdowns Walkdown Standards System Engineering System Work Assignment Authorization Oral Boards
Technical Document
Page 2 of 42
73TD-0ZZ03
Revision 9.0
Introduction
This handbook is intended to be used by System Engineers as a guideline. The handbook conveys good work practices, general standards and performance expectations regarding conduct of System Engineering activities at PVNGS. It is understood that the guidance in this document will be applied as system and equipment needs dictate. This guidance should be used by each System Engineer to develop an appropriate mix of proactive and reactive activities to ensure an overall acceptable health of their assigned system and equipment. This guidance is not intended to supersede existing Company policies, procedures, or directives. The activities/functions described in this handbook are to be applied to plant systems monitored by System Engineering. Systems that are to be monitored and the required level of monitoring (e.g., System Health Reports, SENTRI, and Walkdown frequency) are established in the Matrix of Graded Plant Systems, as listed in Appendix C. The matrix applies a graded approach to the monitoring of plant systems.
Mission Statement
System Engineering, as managers of the plant systems, will monitor and trend system performance to prevent equipment failures, reduce system unavailability, increase equipment reliability and improve productivity. We, as system managers, will provide timely technical solutions, understand system design bases and margin and exercise sound engineering judgment to ensure safe and reliable plant operation.
System Engineering Roles and Responsibilities

The System Engineers primary role is to proactively manage system performance to meet or exceed plant safety, production, and cost goals by preventing equipment failures and improving system reliability and availability in a cost effective manner. As the station system expert, the System Engineer is the focal point of plant knowledge concerning systems (i.e., performance requirements and bases, operating status, performance monitoring and analysis, planned preventive, predictive and corrective maintenance, and related industry operating experience). The primary responsibility of the System Engineer is to monitor, trend and communicate on a regular frequency, the performance, reliability and health of assigned systems. This is accomplished by the collection, analysis and trending of system performance data, implementation of the Maintenance Rule and monitoring of preventative, elective and corrective maintenance. In this context, performance monitoring covers system reviews that can be both direct and indirect. A type of indirect system monitoring would entail reviewing the results of station programs or processes. For example, an increasing number of active and outstanding work mechanisms may be an indication that increased attention is needed or that the amount of resources expended on a system needs adjustment. Another type of system monitoring entails review of current system process parameters, which is more direct and real time. For example, trending the results from in-service pump tests may be used to anticipate early pump degradation that can be corrected before it fails an in-service test or fails during plant operation. Optimally, a
Technical Document
Page 3 of 42
73TD-0ZZ03
Revision 9.0
System Engineer should spend half the average work week on performance monitoring and trending for their respective system(s). The PVNGS Nuclear Engineering Roles and Responsibilities Document stipulates the specific organizational accountabilities for System Engineering. These include:

System Engineers are responsible and accountable for the performance of their systems. The System Engineer, is responsible for monitoring, trending and developing comprehensive health reports that accurately portray all aspects of system conditions System Engineers are well integrated into work control process to ensure system deficiencies are integrated into site work schedules System Health reporting is to reflect PM status, single point vulnerability status, corrective maintenance, selective maintenance issues and all maintenance rule issues. Health reporting will reflect a clear integrated strategy to turn system back to GREEN and to maintain systems at GREEN System Health. System Engineers shall develop and manage recovery plans for RED/YELLOW Systems System Engineers support surveillance testing, survey important work activities in progress and perform scheduled walkdowns to ascertain system material condition Implement Maintenance Rule (10CFR 50.65) requirements by collecting, monitoring and evaluating system performance data against established performance goals/criteria. Develop plans of action to remove systems from the Maintenance Rule (a)(1) category to the (a)(2) category and aggressively monitor their implementation. Develop long range plans for major maintenance activities, component replacements and design changes. This includes sponsoring needed engineering changes and ensuring their functional requirements are satisfied Actively review and incorporate Operating Experience (OE) as appropriate to address issues and improve system health. The System Engineer ensures that issues and action plans are communicated clearly and timely to management and affected Palo Verde organizations. All communication with the NRC should be documented and provided to NRA and System Engineering management.
Technical Document
Page 4 of 42
73TD-0ZZ03
Revision 9.0
Performance Monitoring and Trending

The primary task of the System Engineer is to monitor, trend and communicate on a regular frequency, the performance, reliability and health of their assigned systems. This will be accomplished by collecting, analyzing and trending system performance data and through active implementation of the Maintenance Rule. System performance is tracked in SENTRI (System Engineering Network for Trending and Reporting Information), routinely reported through the System Health Report and adverse trends or material condition issues are addressed in the corrective action program. The following are the expectations, tools and resources for Performance Monitoring and Trending (CRAI 3060770). 4.1 System & Component Performance Parameter Monitoring The System Engineer shall establish the system and component operating parameters and that will be monitored. These parameters and associated acceptance criteria are documented in EPRI-based SYS MON and monitored using SENTRI. The purpose of performance monitoring is to proactively identify and correct degrading equipment and system performance. The System Engineer should document any issues that are identified through system performance monitoring and trending in the System Log of SENTRI and correct issues via the corrective action program with the generation of a PVAR. Specific SENTRI Monitoring requirements include: Use of SENTRI System performance at PVNGS is primarily monitored via SENTRI. Therefore, it is important that the tool be utilized on a daily basis. Issues should be reported at the System Engineering Department Plant Status Meeting. In addition to a daily system status review, the following explicit expectations are to be addressed. Control Panel The control panel within SENTRI is the cover page for the System Engineers system. It is an expectation that the control panel be up to date and a correct reflection of System Status. Information acknowledgement, Alarm Acknowledgement and Significant Issues must be current. Unit Scorecards need to be constantly reviewed and updated. Alarm Acknowledgement 1. Timing Anomalies in system performance are identified via SYS MON parameter alarms specified by the System Engineer. The review and acknowledgement of these alarms is important in the prompt identification of adverse trends. As such, it is the department expectation that all parameter alarms be acknowledged within one (1) week of receipt.
Technical Document
Page 5 of 42
73TD-0ZZ03
Revision 9.0
2. Documentation For alarms that warrant action (e.g., PVAR, increased monitoring, trending), the System Engineer shall make an entry in the SENTRI System Log. Action Plans For system health and Maintenance Rule issues it is the expectation that an action plan be documented by the System Engineer. The three (3) categories of required action plans are Red/Yellow System Recovery Plans, Significant Issue Action Plans and Maintenance Rule (a)(1) Action Plans. The requirements for the generation and maintenance of action plans are as stated below (CRAI 3099790). 1. Recovery Plans Recovery Plans are not maintained within SENTRI. These plans are maintained on the System Engineering Website and are required to be updated monthly and provided to the Plant Health Committee (PHC). The recovery plans should contain the required actions to restore system health to GREEN status and should provide sufficient detail such that Plant Management and the PHC can make informed decisions on improving system and equipment performance. All recovery plans shall be entered into the corrective action program and CRAIs generated for each action. 2. Significant Issues System Issues that are considered sufficiently important to be designated as Priority 1 Significant Issues within SENTRI shall have an associated action plan. Priority 1 issues are defined as problems/concerns that are impacting or likely to impact the health of the system. By definition, the issues should be captured in the corrective action program and the associated corrective actions (i.e., CRAIs, corrective maintenance, DF/DM WOs) should be listed and tracked in the action plan. These action plans need to remain current and shall be reviewed on a monthly basis and updated as necessary. Lower priority action plans (i.e., Priority 2-9) are to be developed at the discretion of the System Engineer and should be maintained in SENTRI as active logs, tracking progress of resolution 3. Maintenance Rule (a)(1) Systems that are placed in Maintenance Rule (a)(1) shall have an action plan within SENTRI and designated as such. Per procedure 70DP0MR01, Maintenance Rule, Goal Setting requires the development of a corrective action plan. In general, corrective actions are initiated by engineering and tracked and implemented through the CRDR process. This information should be captured by the System Engineer in the MR (a)(1) action plan within SENTRI. Additionally, the Goal Setting process requires the establishment of goals that demonstrate the effectiveness of corrective actions. The action plan should include an adequate discussion on goals/criteria, Maintenance Rule Expert Panel results, changes and projected return to (a)(2) status. As with Significant Issues, these plans shall be reviewed on a monthly basis and updated as necessary.
Technical Document
Page 6 of 42
73TD-0ZZ03
Revision 9.0
4.2
System Walkdowns, In Plant Observations and Documentation In addition to data trending, the System Engineer needs to periodically observe and walkdown their assigned system(s). This form of monitoring is important in maintaining current awareness of system condition and performance, as many degraded or degrading conditions may not be apparent via performance data review. System Engineering shall support two (2) types of system/equipment walkdowns 1. Weekly Material Condition Inspection of Safety-Significant Equipment 40DP-9ZZ03 40DP-9ZZ03, Section 2.3 requires that Plant Engineering provide personnel to participate in the Material Condition Walkdown. Appendix A, Material Condition Inspection Schedule, outlines the Inspection Areas to be inspected in accordance with the Site 12 Week Schedule. System Engineering has developed a Database/Notification System to schedule personnel for these walkdowns. Eligible personnel have been provided by System and Component Engineering Leadership. Per Section 4.1 of 40DP-9ZZ03, these inspections are normally performed on Tuesdays, starting with a pre-job brief by the lead STA. The Database/Notification System will send out two and one week notifications to the responsible engineer. It is the engineers responsibility to report for the walkdowns, participate and record walkdown completion and engineering related findings in the Database. If a schedule conflict arises, it is the responsibility of the engineer to identify an alternate. 2. System Walkdowns System Walkdowns are an important element of system management, monitoring and trending and the timely identification of material condition issues. A system walkdown is a formal System Engineering task that involves a detailed and comprehensive inspection. Documentation of the system walkdown, data obtained, system status and any PVARs generated shall be documented in the SENTRI System Log. The System Walkdown is: A structured, systematic process A detailed look at system material condition, operation and configuration, degraded or nonconforming SSCs, outstanding work activities and temporary modifications. A detailed review of the material condition of the area surrounding the subject(s) of the walkdown.
Technical Document
Page 7 of 42
73TD-0ZZ03
Revision 9.0
The System Walkdown is not: Observations made during plant support activities Observations of surveillance or maintenance activities The System Walkdown should: Encompass all or part of the total accessible system, such that the entire system is covered over time. A plan should be developed to document the timeframe for accessibility. For example, portions of the system that are inaccessible during power operation should be walked down during refueling outages or SNO outages. In addition to the normal frequency, System Walkdowns should be conducted prior to outage scope milestone dates to support the identification of actions prior to the outage milestone. Items identified after outage scope freeze shall be requested via the Scope Change Request (SCR) process. Upon identification of any discrepancy that may challenge the operability of an SSC, notify the Shift Manager immediately and generate a PVAR in accordance with 01DP-0AP12. Frequency 1. A system walkdown for each PVNGS unit shall be performed on a frequency specified in Appendix C. These frequencies are specified based on access and safety significance. For systems requiring quarterly walkdowns, it is recommended that one walkdown be performed per month to meet the requirement. Scheduling will be left to the discretion of the System Engineer based on consideration of work priority, system accessibility etc. 2. It is recommended that on an annual basis, an Engineering Leader participates in the System Walkdown. The System Engineer should notify their Section Leader, Department Leader and the Plant Engineering Director of scheduled walkdowns. Checklist 1. Each System Engineer should develop their own System Walkdown Checklist. Checklists are essential in ensuring the proper scope is covered. The checklist is not a formal document and does not require retention, but can be used for logging purposes. Information that should be contained in a system walkdown checklist is provided in Appendix D.
Technical Document
Page 8 of 42
73TD-0ZZ03
Revision 9.0
Documentation 1. Documentation of the walkdown, data obtained, system status and any PVARs generated shall be documented in the SENTRI System Log. 4.3 Equipment Failure Monitoring As part of system and component monitoring, the System Engineer shall review the Failure Data Trending (FDT) report per procedure 30DP-0RA01, Component Failure Trending to determine if there are any adverse trends. If the System Engineer determines that further evaluation is warranted based on the High Failure Rate or Increased Failure Rate, then a PVAR shall be initiated to identify the trend within the corrective action program and to document the evaluation and action taken. Additionally, the system engineer reviews the FDT report quarterly to look for Maintenance Rule Functional Failures (MRFF) (See Section 5) that may have been missed during the work request generation process. The Failure Data Trending (FDT) Quarterly Failure Report is accessed through the FDT Web page (http://fdt/). The report lists all Palo Verde failures reported to the Component Trending module of the SWMS database. The report excludes incipient failure conditions. Incipient conditions include: out of calibration conditions in which the component is recalibrated only, conditions in which a component function is not degraded, and conditions involving indication only failures. Finally, the documentation of the report review shall be made by the System Engineer within the SENTRI Log. The review should be completed and documented with 20 days. For systems with System Health Reports, the review is also documented in the System Health Report. 4.4 Cross System Failure Monitoring The System Engineer shall review the FDT Cross-System Failure Report (CSFR) quarterly. The FDT Cross-System Failure Report is based on PVNGS failures reported to the Component Trending module of the SWMS database for a specific Manufacture and Model number. The CSFR is accessed through the FDT Web page (http://fdt/). The review of the FDT Cross-System Failure Report is used to identify adverse trends in component failures across systems. The report excludes component failures identified as incipient failure conditions. As with the FDT report, this reporting and review requirements are in accordance with 30DP-0RA01, Component Failure Trending. A feature in the CSFR is the ability to display failure statistics. When the failure rate for a component exceeds two (2) standard deviations, the window is colored red. This allows for easy identification by the system engineer that a component may be exhibiting abnormally high failure rates.
Technical Document
Page 9 of 42
73TD-0ZZ03
Revision 9.0
In the Cross System Failure Report, equipment is grouped by system component code, manufacture code and manufacture model number. Based on engineering judgment, when a System Engineer determines that further evaluation of a failure trend is warranted, a PVAR shall be initiated to identify the trend and to document the evaluation. The documentation of the report review should be made by the System Engineer within the SENTRI Log within 20 days. For systems with System Health Reports, the review is also documented in the System Health Report. 4.5 Industry Operating Experience (OE) Review 4.5.1 Purpose and scope Operating experience (OE) is used to prevent events, avoid equipment failures, learn lessons from human performance errors, and improve station performance. Lessons learned through the use of operating experience should be institutionalized through changes to station processes, procedures, equipment, and training programs. The System Engineer is expected to remain cognizant of applicable operating experience both at Palo Verde and within the industry. As a minimum, the System Engineer should review appropriate NRC and INPO websites and publications, paying especially close attention to those issues that have a direct effect on the system and components within the engineers scope of responsibility. The station requirements for the review and assessment of OE are defined in procedure 65DP-0QQ01, Industry Operating Experience Review. In addition to learning from other stations sharing in-house operating experience information with the industry is an integral part of the Industry Operating Experience Program. The foremost criterion for reporting and sharing in-house operating experience to the industry is that the information may benefit other stations in identifying similar conditions and allow timely corrective actions to prevent a similar event. The decision to share information is best determined by asking the questions, "If this event had occurred at another station, would I want to know about it?" and "How quickly?" INPO has established a median timeliness goal of 50 days for OE message reporting (CRAI 2928244). A related performance metric is available on the INPO Plant Information Center website. 4.5.2 Documentation The classification, review and documentation of high-tier OE is defined in 65DP-0QQ01. Low tier OE is identified and disseminated at the department level and entered into the System Engineering OE Database (CRAI 3122538). Low-tier OE should be evaluated with respect to possible application to PVNGS. Documentation of the review for the SHR review period shall be documented in the SHR as either applicable or not applicable. Applicable OE
Technical Document
Page 10 of 42
73TD-0ZZ03
Revision 9.0
requiring further evaluation and or corrective action should be entered into the Corrective Action Program via a PVAR. In addition to INPO OE review, the System Engineer should perform an EPIX (Equipment Performance & Information Exchange) review as part of the biannual SHR development.
Maintenance Rule
5.1 10CFR 50.65, Requirements for Monitoring the Effectiveness of Maintenance at Nuclear Power Plants became effective on July 10, 1996. Paragraph (a)(1) of this regulation, commonly known as The Maintenance Rule, requires that goals be established to promote improved performance of structures, systems and components (SSCs) unless, pursuant to paragraph (a)(2) their performance indicates that they are effectively maintained by the preventative maintenance program. The role of the System Engineer is critical to the implementation of the Maintenance Rule. Some of the primary tasks in conjunction with the Maintenance Rule Program and the Maintenance Rule Expert Panel include (CRAIs 3095574 and 3060770):

(a)(2) to (a)(1) placement (a)(1) to (a)(2) return (a)(1) goal setting (a)(2) monitoring Data collection for the (a)(3) Periodic Assessment Determination of components and structures scoped into the Maintenance Rule Establishment of Performance Criteria Maintenance Rule Functional Failure Determinations
5.2
Detailed Responsibilities 5.2.1 Per 70DP-0MR01, Maintenance Rule, the System Engineer establishes the Maintenance Rule performance criteria for their system. These criteria evaluate the reliability and unavailability of the system and the associated components. The Performance Criteria should be established to allow effective monitoring of all system Key Safety Functions within the scope of the Maintenance Rule. Additionally, the System Engineer will provide written documentation of how the system performance criteria were developed and the method of development. This information will be included in the Performance Criteria database. Final performance criteria must be approved by the applicable System Engineering Section Leader. The System Engineer evaluates CRDR/PVAR conditions for Maintenance Rule Functional Failures (MRFFs). For any MRFF that causes a system to exceed its Page 11 of 42
5.2.2
Technical Document
73TD-0ZZ03
Revision 9.0
performance criteria or established goals, the System Engineer ensures a root cause evaluation is performed within the Corrective Action Program (CAP) such that corrective actions to prevent recurrence of a functional failure be established. 5.2.3 The System Engineer reviews the FDT Quarterly Failure Report once a quarter. This helps ensure that MRFFs have not been missed during the normal processing of CMs and CRDRs. If the System Engineer identifies an MRFF that is not already documented by a CRDR, then the engineer will initiate a PVAR. The System Engineer is responsible for reviewing the SSC performance data on a routine basis to determine if the SSC is still performing within the limits set by the performance criteria. Should performance criteria be exceeded, then the System Engineer is responsible for convening the Maintenance Rule Expert Panel (by contacting the Maintenance Rule Group) to evaluate the issue for (a)(1) placement. For systems that are placed into (a)(1) monitoring status, the System Engineer will develop action plans and schedules for returning systems and component to (a)(2). Specific requirements are provided in Appendix H of 70DP-0MR01. Mitigating Systems Performance Index (MSPI) system Performance Criteria for the Safety Injection High Pressure Safety Injection (HPSI), Safety Injection Containment Spray (CS), Auxiliary Feedwater (AF), Diesel Generator (PE/DG), Essential Cooling Water (EW), and Essential Spray Ponds (SP) must be approved by the System Engineer and applicable Engineering Section Leader and concurred on by the PRA and Maintenance Rule sections within the Nuclear Risk Management Department. These Performance Criteria are documented in the Performance Criteria Database maintained by Nuclear Risk Management. The System Engineer is responsible for providing the Maintenance Rule Group with the performance information needed to support the required Maintenance Rule (a)(3) periodic assessment. For Low Risk Significant (LRS) Systems without a System Engineering Organization System Health Report, a 70DP-0MR01 Appendix G - Low Risk Significant System Performance Review will be used semi-annually to monitor the LRS System status. The completed forms are forwarded to the Maintenance Rule Coordinator to provide information for the (a)(3) Assessment in July for the first half of the reviewed year and January for the last half of the reviewed year. The review is completed each year.
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8
Technical Document
Page 12 of 42
73TD-0ZZ03
Revision 9.0
Work Management
6.1 The ability of the System Engineer to influence the overall condition of their systems is improved through effective alignment between Work Management and System Engineering. As such, it is important that the System Engineer identify work activities as early as is reasonable to support site work management goals. The early identification of work activities allows proper work planning, scheduling and timely implementation. System Engineering must also consider transportability of issues early enough to support proper outage scheduling and planning. The System Engineer should routinely review the outstanding WMs associated with their system. The purpose of the review is to stay knowledgeable on system problems and to provide appropriate input to scheduling process. The System Engineer while reviewing the WMs should consider impact to areas such as Maintenance Rule unavailability, outage milestone considerations, and overall work priority. Based on these objectives, the following lists specific responsibilities with respect to Outage and Online Work Management. 6.1.1 Online System Engineers have procedural requirements to support the 12 week work schedule as identified in procedure 51DP-9OM03, Site Scheduling. The Online Work Management Process begins with the identification of the right work in the T-18 week. Once the right work is identified, engineering deliverables, parts procurement and work order preparation windows open for appropriate disposition. The System Engineer reviews the scope objectives and priorities for the systems selected for the work week window. Right work is selected based on the highest value work for the health of the system. Consideration is work with due dates defined in recovery plans to improve system health color from red/yellow to white. Maintenance rule issues, station top ten and CAP related items are flagged. Prioritized and commitments obtained. If these important work activities are in jeopardy then the system engineer should elevate the discussion and decision making to the Work Week Manager and Plant Engineering Director. The system engineer shall also be cognizant of Corrective and Preventative Maintenance that adversely impacts unavailability and identify opportunities where work can be bundled or deferred from online.
Technical Document
Page 13 of 42
73TD-0ZZ03
Revision 9.0
6.1.2
Outage System Engineers need to be cognizant of Outage Milestones for the timely identification of work for support of well planned and safe unit outages. The specific milestones and station expectations are defined in 51DP-9OM09, Outage Planning and Implementation. This procedure also contains the requirements for processing a Scope Change Request (SCR). It is recognized that important work items may be identified after outage scope freeze. It is the expectation that these items are identified promptly with the generation of a PVAR and immediately followed up with the generation of an SCR with appropriate justification regarding the need for performance of the work activity. The System Engineer should track the item through WM scoping and SCR approval.
6.1.3 Modifications The System Engineer is responsible for reviewing initiated DM Work Orders (DMWO @ LOC 170) for scope identification and prioritization (81DP-0EE02). The System Engineer is responsible for ensuring the completion of the Design Change Request (DCR) with input from PVAR initiator. Development of the DCR includes defining a problem statement, the proposed modification scope, and options/alternatives considered. The System Engineer as the modification sponsor provides recommendations for prioritization, design and implementation windows to the Plant Health Committee Subcommittee (PHCSC) within 60 days of assignment to System Engineering for disposition within the 3 Cycle Plan. During the resource analysis and design stage, the System Engineer also provides technical support as needed. 6.1.4 Long Range Planning The System Engineer is responsible for the long range planning of major improvements to their respective systems. The long range system performance improvement plans will focus on the elimination of in-service equipment failures; optimizing system operating efficiencies and addressing system and equipment obsolescence. Modifications and major maintenance activities should be identified by the System Engineer in accordance with Site Policy 0700 Long Range Plan. Per the Policy, PVNGS shall have a published Long Range Plan whose purpose is to provide guidelines to systematically plan for major projects (i.e. each individually equal to or greater $300,000), funded as capital or operations and maintenance (O&M), including plant modifications, major maintenance activities and projects. It is the initial intent that this process plans major projects for a minimum of six years and strives to be a ten year look-ahead. Additionally, this process takes into account life cycle management to ensure PVNGS is able to safely and efficiently generate electricity for the long term.
Technical Document
Page 14 of 42
73TD-0ZZ03
Revision 9.0
System Health Report

7.1 Purpose and Scope 7.1.1 The System Health Report (SHR) is used as an indicator of the general effectiveness of PVNGS programs and processes to maintain and improve system material condition and performance; it is a snap shot in time of the health of the system (CRAI 3060770). The System Health Report provides a color rating; GREEN, WHITE, YELLOW or RED to indicate the overall health of the specific monitored system for the indicated period. The objective of the report is to provide an effective tool that the System Engineer, Plant Health Committee (PHC) and Senior Management will use to focus resources and attention on systems that currently or in the future will not meet performance objectives. A system with a green rating reflects a situation where the issues identified require no extra resources or attention to ensure the system continues to meet performance objectives. For Systems with Red and Yellow windows, the System Engineer shall develop a Recovery Plan for improving the system health to White or Green (Road to Green). In order to ensure objective and consistent health reporting for the station, specific guidance is provided in Appendix A with respect to rating criteria, report content, frequency of issuance and recovery plan requirements.
Testing
8.1 Through a strong knowledge of system design and operation and its effect on overall plant operation and of system response under normal, test, and transient conditions, the System Engineer has an important role in all testing required to demonstrate the ability of structures, systems, and components to function satisfactorily within the boundaries, limits and criteria delineated in design or license documents. System testing whether its surveillance testing, post-modification or post-maintenance testing are not owned by System Engineering, however involvement includes the following:
Evaluation, as needed, of surveillance test results. Test results should be reviewed for compliance with procedural acceptance criteria and overall system performance requirements. System, component, and/or procedure deficiencies should be identified and corrected in a timely manner consistent with operating requirements. Assist in or review performance of special tests and review results for evaluation of system performance. Determine the causes of system malfunctions and recommend corrective action.
Technical Document
Page 15 of 42
73TD-0ZZ03
Revision 9.0
Maintain knowledge of system modifications, including appropriate design details, licensing aspects, construction and installation status, and postmodification (DVT) testing. This includes support, as needed, in the development of test requirements, process and acceptance criteria for DVT instructions.
Margin Management
9.1 The system and component design basis is protected by establishing documented limits for design requirements and operational configuration using sufficient margins. Margins exist for the design to assure conformance with the design basis, demonstrating compliance with regulations, defining preventive maintenance schedules, performing operability evaluations and making design change determinations. A margin is a buffer or cushion established to provide for contingencies or unanticipated situations ensuring that defined limits will not be reached. Many types of margins exist.
Unanalyzed Margin The amount of conservatism beyond the analyzed or calculated design that ensures the ultimate capability will not be reached. Unanalyzed margin results from uncertainties in design, materials, fabrication, or conservative analysis assumptions and methodology. An exact value for this margin may not be accurately determined in some cases. Design Margin The conservatism identified during the design process that exists between the operating limits and the analyzed design boundary. Design margins can be defined by engineering judgment or by industry code defined values. Operating Margin The amount of buffer beyond the normal operating range to ensure that the design limits are not approached. Safety Factor A type of margin where a multiplier is applied to a calculated or defined value to ensure that ultimate failure will not occur. Maintenance Margin - The margin adjustment associated with the physical condition and reliability of an SSC. For example, an isolation valve with a history of significant leakage could reduce the margin in a fluid system. Unreliable HVAC components could affect critical equipment in the area. Complexity Margin - The margin adjustment associated with the complexity of the design associated with an SSC. A more complex design may be more vulnerable to failures, and is more likely to include a design error that could result in a potential common mode failure.
Technical Document
Page 16 of 42
73TD-0ZZ03
Revision 9.0
Margin can be tracked by setting up a Margin Model (see below)
The system engineers role in margin management is to identify and document (in SENTRI and SHRs) low margin issues, and present and prioritize actions to be taken to recover margin to the Plant Health Committee. This is accomplished by identifying low operating margin items that are associated with the system or components based on trending data and tests. Additionally, design and licensing margin issues are identified by gathering information from Design and associated Component and Program engineers with interfaces for the system.
Analyzed Design Limit Operating Limit

Tech Spec Limit HI-HI Alarm HI Alarm
Unanalyzed Margin Design Margin
Operating Margin
Normal Operations Range of Normal Operating Margin Operation
Technical Document
Page 17 of 42
73TD-0ZZ03
Revision 9.0
10 Training and Qualification of System Engineers

10.1 Scope and Description Per INPO 85-033, Use of System Engineers, System engineers are required to develop and maintain knowledge of the system status and will be considered the plant expert for their assigned plant system(s). As such, the use of initial and continuing training to ensure system knowledge development is critical to the success of an effective System Engineering organization. System Engineers fall under the INPO Accredited Engineering Personnel Training Program and are subject to the requirements of the Palo Verde Engineering Training Program Description (TPD) for general and continuing training and task oriented qualification. With respect to specific System Engineering qualification, a demonstrated level of assigned system knowledge is accomplished through the completion of the System Engineer Work Assignment Authorization (see Appendix B CRAI 2895670). The process contains required reading, training (CRAI 2987496), mentoring and knowledge demonstration. Newly assigned system engineers or system engineers assigned new systems are required to complete the Work Assignment Authorization (WAA) (CRAI 2825660). The requirement for a WAA does not limit/inhibit the engineers ability to perform task(s) for which separate qualification standards have been identified by training or job qualification cards (JQCs). The minimum level of knowledge required to be demonstrated by a System Engineer prior to assuming responsibility for a system is to be able to: Accurately judge the significance or applicability of incoming information such that the System Engineer will be able to assess the potential impact of the information and initiate appropriate actions when the integrity of the systems, structures, components or programs under their area of responsibility could be affected. The Work Assignment Authorization provides assurance of a System Engineers' specific knowledge given an interface with a Technical Mentor, and engineering management. While undertaking completion of the WAA, the engineer will be designated in SENTRI as a System Engineer in Training and for activities stipulated in this handbook, the engineer will be under the mentorship of the assigned Technical Mentor and the supervision of the assigned Section and Department Leader.
Technical Document
Page 18 of 42
73TD-0ZZ03
Revision 9.0
For System Engineers with assigned systems in place prior to June 2006, a completed incumbent analysis has been performed, in lieu of the WAA, and has been transmitted to NIRM under cover letter and the engineering training database is updated to reflect an engineers authorized work assignment. For incumbents only, the incumbent analysis, as documented in SWMS, serves as the basis for a demonstrated knowledge level for the performance of the duties and responsibilities of a System Engineer as delineated in this handbook. It should be noted that the details regarding the form and content of the incumbent analysis, as delineated in Revision 05, have been removed from the handbook. Record copies are maintained in NIRM and the Engineering Training Database. 10.2 Implementation It is the expectation that an engineer that is transferred into system engineering or a System Engineer that is assigned a new system will complete the System Engineering Work Assignment Authorization within 12 months following assignment of a system. While the WAA is in progress, the engineer will be identified in SENTRI as a System Engineer in Training. The engineer will be assigned a Technical Mentor. The Technical Mentor may be a previous incumbent or an engineer approved by the Section Leader as having sufficient and demonstrated experience with the system. Completion of the WAA requires the conduct of an Oral Board. The protocol for conduct of the board is provided in Appendix E. Finally, the System Engineering Department Leader will maintain copies of the in-progress the System Engineering Work Assignment Authorization for easy retrieval. Upon completion of the Work Assignment Authorization, the document is transmitted to NIRM under cover letter and an engineering database is updated to reflect an engineers authorized work assignment. The annotation of System Engineer in Training is removed from SENTRI. The Work Assignment Authorization is not a task qualification record/card. The Work Assignment Authorization is used to document a System Engineers minimum level of knowledge.
Technical Document
Page 19 of 42
73TD-0ZZ03
Revision 9.0
Appendix A System Health Report Guidance

1 Purpose 1.1. The System Health Report is used as an indicator of the general effectiveness of PVNGS programs and processes to maintain and improve system material condition and performance; it is a snap shot in time of the health of the system. 1.2. The purpose of this guideline is to provide the methodology to be used to standardize the content of the PVNGS System Health Reports. 1.3. The System Health Report will provide a color rating; Green, White, Yellow or Red to indicate the overall health of the specific monitored system for the indicated period. 1.4. This guideline also identifies the frequency that the System Health Reports are to be prepared and issued. 2 Definitions 2.1. GREEN - System performance is acceptable and requires no additional significant actions outside normal plant work scheduling process. 2.2. WHITE - System performance has returned to an acceptable status but additional monitoring is required before returning to GREEN or System performance is acceptable but requires increased attention to maintain system performance at acceptable standards. 2.3. YELLOW - System performance / reliability has degraded and issues that affect a system operating parameter requires close monitoring, if not corrected could result in impact to safety or continued plant operations. 2.4. RED - System performance has degraded and is unacceptable for reliable plant operation. Significant system problems exist and system reliability is in question. 3 Responsibilities 3.1. System Engineering Department Leader: 3.1.1. Ensures the specific Health Reports are updated in a timely manner as required by this guideline. Reviews and approves Red/Yellow System Recovery Plans. Updates the applicable Recovery Plan Metrics and presents Recovery Plan status to the PVNGS Plant Health Committee (PHC).
3.1.2.
Technical Document
Page 20 of 42
73TD-0ZZ03
Revision 9.0
3.2. System Engineering Section Leader: 3.2.1. Reviews each specific Health Report to ensure the report meets the requirements of this guideline. Leads presentation of SHR to PVNGS Management and as requested to the PHC.
3.2.2.
3.3. System Engineer: 3.3.1. 3.3.2. Develop the System Health Report per the requirements of this guideline. Ensures the Health Report is discussed with each applicable department at the discretion of the engineer, prior to routing to the responsible Section Leader. For example, if there was a significant chemistry issue on a system, the engineer should discuss the issue with chemistry prior to including the issue into the report.
System Health Indicators 4.1. The System Health Report should reflect the actual real time condition of the system performance for the evaluation period. The System Health indicator (color) is a snap shot in time and is not to be made based on future plans or actions. System Health indicators are provided in Table 1. 4.2. The following six (6) performance areas will be assessed in order to determine the overall system health:

Operational Performance Material Condition Maintenance Rule System Performance Monitoring Significant Issues Life Cycle Management
4.3. Criteria are established for determining one of the four (4) colors for each of the attributes identified for the six (6) performance areas and, through an algorithm, an overall Unit color is assigned for the system designating Unit system health. Overall system health is determined by grouping unit colors.
Technical Document
Page 21 of 42
73TD-0ZZ03
Revision 9.0
4.4. For the identified performance areas, the associated SENTRI categories should be tracked on the report scorecard as a minimum. Additional areas can be added at the discretion of the System Engineer. 4.5. The overall system, unit or individual area system color may be over ridden if it does not accurately reflect the state of the system. The override shall only be to a color of lesser performance, e.g. green to white or yellow to red. Override requires the concurrence of the Section Leader. EXAMPLE: A system that is chronically unavailable may not have a significant maintenance backlog or several operator workarounds, but still warrants increased attention and therefore can elevate the color of the window. 4.6. The System Unit Level Color is determined by summing the indicators as stipulated in Section 6. 4.7. A System Recovery Plan shall be prepared for every Red and Yellow System. The plan format should be in accordance with the Road to Green Recovery Plan template located on the System Engineering Website. For each recovery plan, a tracking PVAR/CRDR should be generated with recovery plan actions tracked via linked CRAIs. 5 System Health Report Content 5.1. A System Health Report Content template/example is provided on the System Engineering website, and provides guidance on what is to be discussed in each section of the Health Report. 5.2. The basis for the individual window color (refer to Section 6.4) needs to be clearly stated in the health report in the Color Basis section of the report. 5.3. At a minimum, every attribute identified in Table 2 (System Level Criteria) will be addressed in the individual reports to provide management with appropriate and consistent information. Information can be based on site specific goals or initiatives. If the specific topic is not applicable to the specific system, so indicate in the health report. All topics must be addressed in the health report. 6 System Level Criteria 6.1. The intent of the System Level Criteria Table is to provide objective guidance (where available) for assigning window colors for the applicable attributes associated with the six (6) performance areas for each system.
Technical Document
Page 22 of 42
73TD-0ZZ03
Revision 9.0
6.2. The overall system color or individual attribute color may be over ridden if it does not accurately reflect the state of the system. The override shall only be to a color of lesser performance, e.g. green to white or yellow to red. Override requires the concurrence of the Section Leader. EXAMPLE: A system that is chronically unavailable may not have a significant maintenance backlog or several operator workarounds, but still warrants increased attention and therefore can elevate the color of the window. 6.3. Once the individual unit attribute conditions for each system are determined, the attribute window colors are each assigned the following numerical values:

Green = 0 White = 1 Yellow = 2 Red = 3
6.4. The Unit Level Color is determined by summing the assigned points for attribute indicators.

0-5 = Green 6-9 = White 10-12 = Yellow >12 = Red
6.5. The System Color is determined by combination of Unit color

Green - All units green or two units Green, one unit White White 2-3 units White, or two units green/white, one yellow Yellow - All units Yellow, or two units Yellow, one White or Green or two units Green, one unit Red Red 2-3 units Red, or two units Yellow, one Unit Red Page 23 of 42
Technical Document
73TD-0ZZ03
Revision 9.0
6.6. The system health reports should be updated at least twice per year and posted one month following the end of each update period, unless a deviation to the update frequency is approved by the System Engineering Department Leader.
Technical Document
Page 24 of 42
73TD-0ZZ03
Revision 9.0
Table 1 - System Rating Guide and Level Criteria
System Status Rating Definitions

Rating Color Performance
Excellent
Action
System performance is acceptable and requires no additional significant actions outside normal plant work scheduling process. System performance has returned to an acceptable status but additional monitoring is required before returning to GREEN or System performance is acceptable but requires increased attention to maintain system performance at acceptable standards. System performance / reliability has degraded and issues that affect a system operating parameter requires close monitoring, if not corrected could result in impact to safety or continued plant operations. System performance has degraded and is unacceptable for reliable plant operation. Significant system problems exist and system reliability is in question.
Green
White
Acceptable
Yellow
Needs Improvement
Red
Not Acceptable
Trend
Performance
Improving
Description
Objective evidence evaluated by the System Engineer indicates that the performance of the system or system group is improving or expected to improve. Performance is expected to remain essentially unchanged. Objective evidence evaluated by the System Engineer indicates that the performance of the system or system group is degrading or expected to degrade.
Neutral
Degrading
Technical Document
Page 25 of 42
73TD-0ZZ03
Revision 9.0
Table 2 - System Level Criteria (Typical)

GROUP ATTRIBUTE
Unit Unplanned Capacity Loss resulting from a system/component failure or degradation during past 6 months OR previous events for which corrective actions are not complete
CRITERIA
Green: 0 MW-Hr Loss (per Unit) White: < 1000 MW-Hr Loss (Per Unit) Yellow: 1000- 5000 MW-Hr Loss (Per Unit) Red: > 5000 MW-Hr Loss (Per Unit)
Unplanned LCO entry events during past 6 months OR previous events for which corrective actions are not complete
Green: No unplanned shutdown LCO Entry White: 1 Unplanned shutdown LCO Yellow: 2 Unplanned shutdown LCO Entries Red: 3 Unplanned shutdown LCO Entries or 1 LCO that leads to a Unit Shutdown
Operational Performance
Operator Work-Arounds
Green: None Yellow: : > 0 Red > 0 and older than 1 Full Operating Cycle
Operability Determinations
Green: No operability evaluations performed White: 1 Operability evaluation performed Yellow: 2 Operability evaluations performed Red: 3 or more Operability evaluations performed
Open Temp Modifications
Green: None White: 1 Tmod Yellow: > 1 Tmod Red: > 1 Tmod and older than 1 Full Operating Cycle
System Walkdown results
This attribute color will be at the discretion of the System Engineer. Color should depend on material condition findings from performance of System Walkdowns. Findings from other related walkdown findings (i.e., Operations and Maintenance) should also be considered. Green: 0 White: 1 per Unit Yellow: 2 per Unit
Material Condition
Online Corrective Backlog (Open type CM WOs) INPO defines CM (Corrective Maintenance) Backlog is the classification of any work on power block SSCs where the SSC has failed or is significantly degraded to the point that failure is imminent (within operating cycle/PM Interval) and no longer conforms to or is capable of performing the SSC's design function.
Red: Any > 18 Months old
Technical Document
Page 26 of 42
73TD-0ZZ03
Revision 9.0
GROUP
ATTRIBUTE
Degraded/Non-Conforming Conditions for which scheduled corrective actions are not complete. Green: : None
CRITERIA
White: 1 online WM older than 168 days or Pri 5 > earliest outage Yellow: Red: 3 older than 168 days or Pri 5 > earliest outage 5 older than 168 days or Pri 5 > earliest outage
Material Condition
Aggregate Review of all Open WOs (Corrective and Elective) (CRAI 3102752) The INPO definition of EM (Elective Maintenance) backlog is the classification of any work on power block equipment in which identified potential or actual degradation is minor and does not threaten the component's design function or performance criteria.
This attribute color will be at the discretion of the System Engineer to review the aggregate effect based on quantity and age of open material condition work mechanisms
Maintenance Rule (Add - KPI/MSPI for applicable systems in comments section)
Green: (a)(2) White: (a)(1) in Monitoring Stage or near (a)(1) (e.g., Reliability and/or Unavailability near limit) Yellow: MR (a)(1) Action Plan approved and working
Maintenance Rule
Maintenance Rule (Reliability)
Red: MR (a)(1) root cause or action plan in development phase Set attribute color in accordance with MR Performance Criteria
Maintenance Rule (Unavailability)
Set attribute color in accordance with MR Performance Criteria
Predictive Maintenance (PdM)
Green: No Key Components on Watchlist White: 3 Key Components in Reliability Enhancement
Yellow: Any Key Component on in Alert Red: Any Key Component in Alarm
System Performance Monitoring
Inservice Testing (IST)
Green: No Key Components exceeding Alert Range (pumps) or Reference Range (valves) Yellow: Any Key Components in Alert Red: No Key Components exceeding Required Action range
System Health Trends (Identified per System Alarms, Adverse component trend, CRDRs etc)
Green: All Parameters Normal Yellow: Abnormal Trend in one or more components Red: Adverse Trend in one or more components (PVAR initiated and Corrective Actions NOT complete OR not in outage schedule
Technical Document
Page 27 of 42
73TD-0ZZ03
Revision 9.0
GROUP
ATTRIBUTE
Open NRC or INPO Issues (Open cited NRC Violations/INPO AFIs) Green: None
CRITERIA
Yellow: > 0 with Corrective Actions Complete OR Scheduled Online/Outage Red: > 0 with Corrective Actions not Complete OR not Scheduled Online/Outage
System Performance Monitoring
PM Program
Green: No deferrals Yellow: Red: 1 deferral 1PM deferred beyond the late date without justification
Significant Issues
Green: No Priority 1 issues White: 1 Priority 1 issue Yellow: Red: 2 Priority 1 issue 3 Priority 1 issues or one Priority 1 issue open >4 years
Significant Issues
Modifications
This attribute color will be at the discretion of the System Engineer. The attribute should consider the aggregate impact of Modification backlogs both design requests that have not been presented/approved by the PHCSC/PHC and Modifications that have not met the approved schedule for design and implementation. Color should also consider ranking of modification(s) with respect to any delays. Green: No unmitigated Single Point Vulnerability issues White: All unmitigated SPVs identified and action plans are on track Yellow: All unmitigated SPVs identified and action plans are behind schedule
Single Point Vulnerabilities (SPV) (CRAI 3060876)
Life Cycle Management

Margin Management
Red: All unmitigated SPVs identified with no action plan established Green: No unmitigated Operational Margin issues White: Operational Margin issue identified and action plans are on track Yellow: Operational Margin issue identified and action plans are behind schedule Red: Operational Margin issue identified with no action plan established Obsolescence This attribute color will be at the discretion of the System Engineer. Consideration should be given to the status of obsolescence items on the PVNGS Long Range Plan (LRP).
Technical Document
Page 28 of 42
73TD-0ZZ03
Revision 9.0
GROUP
ATTRIBUTE
Site Top Ten
CRITERIA
Green: None White: 1 item plan developed and scheduled Yellow: > 1 item or 1 item plan not developed/scheduled Red: >1 item not developed/scheduled
Life Cycle Management
Technical Document
Page 29 of 42
73TD-0ZZ03
Revision 9.0
Appendix B
PVNGS System Engineering - System Work Assignment Authorization (example)
System Engineer: Name of System Engineer Previous Systems Assignments (fill in system designator):
System Being Assigned: Section Leader: Name of Section Leader Technical Mentor: Name of Technical Mentor Check-List a.
(Name of System Engineer) has: Read and understands the ___ system description, system P&IDs
and all applicable Licensing documents associated with the ___ system. The documents that were reviewed are listed below. a. b. c. d. Appropriate chapters of the USFAR Appropriate chapters of the Technical Specification Appropriate sections of the Design Basis Manual Maintenance Rule basis document for the system
Completed the following training
NGS 62 Maintenance Rule Performance Criteria ECT01 Impact of Supporting Systems
Signature: (Signature of System Engineer) date________ b.
(Technical Mentors Name) the Technical Mentor that has (Years of Experience) with the ___ system has evaluated (Name of System Engineer) and approved (Name of System Engineer) to take over accountability and responsibility for the __ system. (Name of System Engineer) has demonstrated
proficiency by performing and understanding the following activities. Describe in detail the operations of the___ system. Understands the applicable Technical Specification requirements and specific design features of the___ system. Understands the current system material conditions. Understands and acknowledges all the current issues CRDRs, OEs with the system. Technical Mentor Signature: _________________date_______
c.
A Panel including the applicable Section Leader, Technical Mentor and an Engineering Training Representative shall be formed. The Panel had an opportunity to ask ___ System related questions of (Name of System Engineer). (Name of System Engineer) has demonstrated to all ___ Panel members that he/she is ready to take over the responsibilities of the ___ System Engineer position. (Name of System Engineer) is authorized to assume the duties of ___ System Engineer.
Section Leader Signature: ___________________date________
Technical Document
Page 30 of 42
73TD-0ZZ03
Revision 9.0
Appendix C Systems Requirements - Trending, Health Reports and Walkdowns

System
AF - Auxiliary Feedw ater AR - Condenser Air Removal AS - Auxiliary Steam CC- Chemical Production CD - Condensate (See CS for Condensers) CE - Turbine Stator Cooling CH - Chemical and Volume Control CI - Chlorine Injection CL - Containment Integrity CM - Chemical Waste CO - Turbine Generator Control Oil CP - Containment Purge CQ - Core Protection Calculator CS - Condensers (See CD for Condensate) CT - Condensate Transfer and Storage CW - Circulating Water DF - Diesel Fuel Oil and Transfer DG - Diesel Generator DS - Domestic Water DW - Demineralized Water EC - HVAC Essential Chilled Water ED - Extraction Steam and Drains ES - Safety Equipment Status System EW - Essential Cooling Water FH - Fuel Handling and Storage FP - Fire Protection FT - Steam Gen Feedw ater Pump Turbine FW - Feedw ater GA - Service Gas GH - Turbine Generator Hydrogen and Co2 GR - Gaseous Radw aste GS - Turbine Steam Seal and Drain GT - Gas Turbines
SENTRI Y Y Y* Y* Y Y Y Y* Y Y* Y Y* Y* Y Y Y Y Y Y* Y* Y Y Y* Y Y Y Y Y Y* Y Y* Y Y
SHR Frequency SA SA NR NR SA SA SA NR SA NR SA NR SA SA SA (AF) SA SA (DG) SA A* A* SA SA A* SA A* SA SA SA A* A* SA* A* SA
MR HR LR N N HR LR HR N HR N HR N N N HR LR HR HR LR LR HR LR LR HR LR LR HR LR N LR LR LR HR
Walkdown Required Q Q A N Q Q Q A N A Q A N Q Q Q Q Q S S Q Q N Q S Q Q Q Q Q Q S Q
Legend
SENTRI Y* (System Loaded into SENTRI but not developed) SHR (System Health Report) - SA (semi-annual), A (Annual), NR (Not Required) Maintenance Rule HR (High Risk), LR (Low Risk), N (non- Maintenance Rule) Walkdowns Q (Quarterly), S (Semi-annual), A (Annual), N (Not Required) Page 31 of 42
Technical Document
73TD-0ZZ03
Revision 9.0

SHR Frequency SA SA SA SA SA NR SA A* NR A* SA SA SA* SA SA SA SA SA SA A* SA SA (GT) A* A* SA A* NR NR NR SA SA SA* SA SA SA SA A* NR Walkdown Required Q Q Q Q Q A Q S A Q Q Q Q Q Q Q Q N Q S Q Q A A Q A A A S Q Q Q Q Q Q Q S A
System
HA - HVAC Auxiliary Building HC - HVAC Containment Building HD - HVAC Diesel Generator Building HF - HVAC Fuel Building HJ - HVAC Control Building HN - HVAC - Anc Bldg/ EOF/TSC HP - Containment Hydrogen Control HR - Radw aste Building HS - Misc Structures HT - Turbine Building IA - Instrument and Service Air LO - Lube Oil LR- Liquid Radw aste MA - Main Generation MB - Excitation and Voltage Regulation MS - Mrule Structures MT - Main Turbine MX - Remote Multiplex (Limited) NA - Non-Class 1E 13.8kv Pow er NB - Non-Class 1E 4.160kv NC - Nuclear Cooling Water NE - Station Blackout - Electrical NG - Non-Class 1E 480 V Sw itchgear NH - Non-Class 1E 480 V Pow er MCC NK - Non-Class 1E 125V DC Pow er NN - Non-Class 1E Instrument AC Pow er (Limited) NQ - Non-Class 1E Instrument AC Pow er (Limited) NZ - Non-Class 1E SMS/MIMS OS - Lube Oil Storage, Transfer, Purification PB - Class 1E 4.16 kv Pow er PC - Fuel Pool and Cleanup PE - Class 1E Standby Generation PG - Class 1E 480v Pow er Sw itchgear PH - Class 1E 480v Pow er Motor Control Center PK - 1E 125 VDC PN - Class 1E Instrument Pow er PW - Plant Cooling Water QA - Normal Lighting
SENTRI Y Y Y Y Y Y* Y Y* Y* Y Y Y Y* Y Y Y Y Y Y Y* Y Y Y* Y* Y Y* Y* Y* Y* Y Y Y* Y Y Y Y Y* Y*
MR HR LR HR LR HR N LR N N N HR LR N HR HR N HR LR HR LR HR HR LR LR HR LR N N N HR HR HR HR HR HR HR LR N
Technical Document
Page 32 of 42
73TD-0ZZ03
Revision 9.0

System
QB - Essential Lighting (Limited) QC - Security Lighting QD - Emergency Lighting QF - In Plant Communications (Limited) QG - Grounding (Electrical Portion) QH - Cathodic Protection QK - Fire Detection and Alarm QJ - Freeze Protection QM - Special Process Heat Tracing RC - Reactor Coolant RD - Radioactive Waste Drain RF - Radioactive Filter Handling RG - Meterology RI - In Core Reactor Instrumentation RJ - COLSS / Plant Computer RK - Plant Annuciator (Limited) RL - Radioactive Laundry Decontamination RM - Main Control Board RZ - Acoustic Alarm Monitoring SA - Engineered Safety Features Actuation System SB - Reactor Protection SC - Secondary Chemical Control SD - ERFDADS SE - Excore Neutron Monitoring SF - Reactor Control SK - Security SG - Main Steam SH - Quality Safety Parameter Display SI - HPSI / SITS SI - LPSI, Containment Spray and Shutdow n Cooling SM - Seismic Monitoring SO - Seal Oil SP - Essential Spray Ponds SQ - Radiation Monitoring SR _ Solid Radw aste SS - Nuclear Sampling ST - Sanitary Drains and Treatment SV - Loose Parts and Vibration Monitoring SW - Sw itchyard, Grid
SENTRI Y Y* Y Y Y* Y* Y* Y* Y* Y Y* Y* Y* Y* Y Y* Y* Y* Y* Y Y Y Y Y Y Y Y Y Y Y Y* Y Y Y Y* Y* Y* Y* Y
SHR Frequency SA NR SA SA A* A* A* NR NR SA SA* NR NR A* SA A* NR A* NR SA SA SA SA SA SA SA SA SA SA SA NR SA SA SA A* NR NR NR SA
MR LR N LR LR LR N N N N HR LR N N LR LR LR N LR N HR HR LR LR HR HR N HR LR HR HR N LR HR LR N N N N HR
Walkdown Required Q A Q Q A A A A A Q Q A N N N N N N N N N Q N N N N Q N Q Q N Q Q N A N N N Q
Technical Document
Page 33 of 42
73TD-0ZZ03
Revision 9.0

System
SW - Sw itchyard, Grid TC - Turbine Cooling Water WC - HVAC Chilled Water XO - RWT ZA - Auxiliary Building ZC - Containment Building ZF - Fuel Building ZG - Diesel Generator Building ZJ - Control Building ZM - Main Steam Support Structure (MSSS) ZR - Radw aste Building ZT - Turbine Building ZY - Outside Areas ZZ - Miscellaneous Structures
SENTRI Y Y Y Y* Y* Y* Y* Y* Y* Y* Y* Y* Y* Y*
SHR Frequency SA SA SA SA (CH) NR NR NR NR NR NR NR NR NR NR
MR HR HR LR HR LR LR LR LR LR LR LR LR LR LR
Walkdown Required Q Q Q Q S S S S S S S S S S
Technical Document
Page 34 of 42
73TD-0ZZ03
Revision 9.0
Appendix D Walkdown Standards

A system/component walkdown is much more than the physical tour of a location, component or area and is regarded as a vital part of a System Engineers responsibilities. System walkdowns should be planned and scheduled, and if possible, be performed with Operations, Maintenance and Component Engineering counterparts. Each System Engineer should develop their own System Walkdown Checklist. Checklists are essential in ensuring the proper scope is covered. The checklist is not a formal document and does not require retention, but can be used for logging purposes. The following are considerations that should be used in the performance of a System Walkdown and the development of a walkdown checklist. Criteria To Be Used When Performing/Developing System Walkdowns a. b. c. d. Safety (nuclear, industrial and radiological safety). The walkdown should be laid out in a sequential manner to minimize time and dose. Changes in plant conditions and the effects on the walkdown should be considered. The System Walkdown plan/checklist should specify each of the following when they apply: Specific equipment to be monitored. Data to be recorded. Criteria for the equipment parameters (expected values and bands). Specific criteria for looking for plant material condition issues will be part of the walkdown plan. e. Pre-Job Brief A pre-job brief should be performed by the engineer and any team members. When a prejob brief is conducted it should include the following: o o f. A review of the walkdown plan. Specific known safety hazards or radiological issues identified and resolved.
Walkdown Checklist The following is a list of typical items that may be checked during a system walkdown: Tagging (e.g., illegible, lying on floor, unusually old, etc.) Equipment Operation. System temperature - proper cooling. System pressures and flows - proper performance. Water levels. Proper equipment identification (labeling and tagging). Equipment operation is not hampered by scaffolding or other obstructions.
Technical Document
Page 35 of 42
73TD-0ZZ03
Revision 9.0
Unauthorized "Operator Aids". Potential new Workarounds, challenges or Chronic issues. Deficiency Tag Accuracy. Contaminated Areas/Catch Basins/Hot Spots/High Radiation Areas. In addition, the following items should also be considered when performing a System Walkdown: 1. Electrical Panels: Missing water plugs or holes/openings in cabinets (water or moisture intrusion can degrade or damage equipment). Unsealed openings in fire, security, ventilation, flood, HELB, radiation, or missile barriers located inside electrical panels. Missing bolts or thumb screws (if missing could violate seismic evaluation). Open doors or back panels (ensure properly closed and latched otherwise could violate seismic evaluation). Mispositioned breaker switches (anything that is different). Dirt or debris covering cooling gratings or filters, including on top of or inside panels (if blocked can prevent cooling and cause heat buildup and subsequent equipment degradation). Check cable trays that are holding panel cables. Cables should not be hanging outside of cable tray (could overstress cable tray). Check cables for proper end termination (Ends taped, labeled and covered, no bare wire). Abnormal sounds or smells are coming from the cabinet (may indicate degraded equipment). Check for heat damaged cable or conduit. General material condition of cabinet rust, dirt, etc. 2. Mechanical Components Abnormal sounds or smells coming from the pump or motor (may indicate degraded equipment). Within the general guidance of good safety practices, bearing housings, motors, and pumps should be checked for excessive heat or vibration. General materiel condition of pump or motor for steam, oil, or water leaks, proper levels in oil reservoirs or sight glasses, missing insulation, proper conduit sealing (may indicate degraded equipment). System gauges for proper operation or typical values (i.e., discharge pressure gauges reading zero when pump not running, otherwise may indicate valve leaks).
Technical Document
Page 36 of 42
73TD-0ZZ03
Revision 9.0
Pump rotation or reverse rotation if part of a dual train common header system (could indicate check valve degradation or isolation valves leaking by). Hot or warm steam-driven pump piping (indicates admission valve leakage). Dirt or debris covering cooling gratings or filters (if blocked could prevent cooling and cause heat buildup and subsequent equipment degradation). 3. Piping and Pipe Support/Hangers Pipe system sagging not associated with low point drains. Unsealed openings in fire, security, ventilation, flood, HELB, radiation, or missile barriers. Interaction or evidence of contact with adjacent structures or components. Evidence of vibration or excessive movement of piping, support or hangers. Missing or loose parts on piping supports or hangers. Degraded piping supports or hangers including welds and building structures. Improper position setting or travel of snubbers or spring type supports. Misalignment or deformation of pipe supports, hangers and structures. Improper fluid level or leakage of hydraulic snubbers. Snubber or spring cans are not pinned. Appropriate clearance between system components and other permanent or temporary structures to allow thermal or seismic movement without damage. 4. General Material Condition Items Leaks (water, steam, oil, air - packing, flanges, joints, fittings, rust on components or floor). Lubrication (sight glasses, bull's eyes, grease cups, grease fittings, valve stems). Handwheels/valve operators (missing, key or pin missing, unlocked, or not labeled). Filters, screens, or louvers (clogged, dirty, or missing). Instruments or gauges [includes control room](out of calibration, inoperable, bent pointers). Drains or drain holes (clogged, blocked, full, screens or grating missing). Lines or Pipes (loose, unbracketed, vibrating, insulation missing or damaged). Fasteners/bolts (loose, stripped, or missing). Indicating lamps (missing, burned out, or missing covers). Control room or local panel annunciators (system annunciators are clear).
Technical Document
Page 37 of 42
73TD-0ZZ03
Revision 9.0
Panels (covers missing, bolts missing or not tightened, dirt and debris inside). Area lighting (bulbs missing or burned out, inadequate to support activities). Look for consistency between all similar parameters (i.e., common suction gauges have similar values). Packing (bottomed out, out of adjustment, dirty or rusted glands). Cables or leads (unsecured, worn or frayed insulation, improper terminations). Motors or generators (dirty, brush rigging pigtails broken, carbon dust, excessive noise or vibration, ground straps loose or missing, electrical arching). Preservation (rust, corrosion, missing or damaged insulation or lagging). Labels (missing, unclear, inaccurate, or pen and ink). Check valves (oscillating lever, banging, stuck open). MOVs (lubricant leaks, missing plugs). Valves (dried grease caked on stem, packing or stem leaks, bent stem). Unsealed openings in fire, security, ventilation, flood, HELB, radiation, or missile barriers. Signs of boric acid leakage on target or source components. 5. Tritium Leak Detection Considerations (CRAI 3304266) Periodic walkdowns by System Engineering is an industry credited form of tritium leak detection in accordance with the guidance of NEI 07-07 Groundwater Protection Initiative Section 1.2.2.c. Per Study APS010-PR-001, an awareness of the following elements are to be considered during an engineering walkdown of systems containing tritium (ref CRAI 3244596): External Tank Inspection - signs of leakage or wet soil. Essential Density Pipe and Condensate Tunnels - signs of moisture or water. Proper Drainage of HVAC components, missing drain caps, and signs of standing water. Irregularities of the soil in the yard areas. Slumping or bulging is indicative of an underground pipe leak. Irregularities in soil near CW intake structure. Potential issues should be communicated to the Groundwater Protection Program Owner and PVARs generated as necessary.
Technical Document
Page 38 of 42
73TD-0ZZ03
Revision 9.0
Appendix E PVNGS System Engineering System Work Assignment Authorization (WAA) Oral Board Protocol
1. Purpose Define when and how System Engineer Work Assignment Authorization (WAA) Oral Review Boards are conducted for the Nuclear Engineering Organization. Upon completion the System Engineer will take over responsibilities of the assigned system in accordance with 73TD-0ZZ03. 2. Responsibilities 2.1. System Engineer will inform the applicable Section Leader when he or she is ready to be scheduled for a System Engineering System Work Assignment Authorization Oral Board. 2.2. The applicable Section Leader is responsible to ensure the conduct of the Oral Review Board is in accordance with the guidance in this document and that the appropriate board package consisting of completed Oral Review Board grading sheets, a copy of the completed System Engineer WAA and other applicable documentation such as remediation plans is completed. 2.3. The applicable Section Leader is responsible for the remediation plan to address any areas of marginal performance. 2.4. The System Engineer and applicable Section Leader are responsible for presenting the results of failure to pass the Oral Review Board to the Training Review Board for the development of an action plan. 3. Board Conduct 3.1. The Oral Review Board will be conducted in a manner that allows the board to determine whether the engineer has acquired a sufficient level of understanding of their assigned System, Structure or Component (SSC). Areas of assessment include system description, system P&IDs, system operation, Technical Specification requirements, system conditions, and all applicable Licensing Documents. 3.2. Board members will grade the engineers knowledge in three categories, specific questions, key topical and overall. 3.2.1.Responses to individual questions will be assessed 3.2.2.Topical Areas (e.g., UFSAR, Tech Specs) will be assessed 3.2.3.The engineers overall knowledge of the SSC will be assessed. 3.3. The board quorum will consist of the applicable Section Leader, at least one engineer who is a qualified technical mentor, and a Training Representative from the Engineering or Training Department. At the discretion of the applicable Section Leader, the board may include personnel
Technical Document
Page 39 of 42
73TD-0ZZ03
Revision 9.0
from other organizations (e.g., Operations, Maintenance, Licensing) that have specific knowledge of the SSC. 3.4. Oral Review Board members shall complete an Oral Board Sheet. 3.5. The System Engineer shall be provided time to answer each question. If the System Engineer cannot answer a question when initially asked, the question may be delayed and the candidate allowed to re-address the question. 3.6. If the board cannot be completed, it will be suspended until the board can reconvene with the same members at a later time. The incomplete Board Package will be collected by the applicable Section Leader. 4. Board Results 4.1. When all areas have been covered, the board will ask the System Engineer to leave the room. 4.2. The board members shall discuss any information necessary to ensure that the proper comments were assigned to each question. 4.3. The board members will discuss each area reviewed and determine an overall status. The following guidelines are provided for addressing failures. 4.3.1. 4.3.2. 4.3.3. If the engineer fails one or more specific question(s), it does not automatically result in an overall failure. This is an informal coaching opportunity. If the engineer fails a specific topical area, the applicable Section Leader will develop a remediation plan. If the engineer fails the overall performance, a Training Review Board will be convened.
4.4. The applicable Section Leader will have the final decision and the overall performance shall be recorded on their evaluation sheet. 4.5. Each Board Member shall complete and sign their Oral Board Sheet. These sheets will be collected by the applicable Section Leader. 4.6. Once the board had reached their decision, the System Engineer will be informed of the results. The board should discuss both strong and weak areas with the System Engineer. 5. Records Processing 5.1. Oral Review Board Records shall be retained for the duration of the System Engineers assignment. 5.2. The completed System Engineer Work Assignment Authorization shall be sent to Engineering Training for update of the Engineering Continuing Training database and transmittal to NIRM.
Technical Document
Page 40 of 42
73TD-0ZZ03
Revision 9.0
System Engineering Work Assignment Authorization Oral Board Sample Questions Note: These questions are designed to match the competency areas for a WAA Oral Board. The board may use these or others to satisfy board requirements. Questions 1. Describe major system interfaces (elec. power, cooling water, support, etc.) and effect or impact on interfacing systems if your system is degraded. Describe major regulatory documents (reg. guides, codes and standards, etc.) applicable to your specific system (do not include documents that are generally applicable to a broad set of systems). Describe the Design Basis function(s) of your system as defined in the UFSAR and the Tech. Spec. basis. Describe applicable Technical Specification (LCOs, SRs) for your system and the associate modes of applicability. Describe the differences between operable and available and inoperable and unavailable. Discuss the functions to be monitored for your system as required by the Maintenance Rule. Describe both Industry and PVNGS specific issues associated with your system. Describe the elements of a System Walkdown What issues/material condition did you discover during a system walkdown? Describe some critical parameters monitored by your System Monitoring Plan. Whats the most challenging aspect of being a System Engineer?
2.
3.
4.
a. 5. 6. 7. a. 8. 9.
10. Are there any tasks you perform as a System Engineer that you believe you need additional information/training on to be successful? 11. Are you comfortable with the knowledge you have on your assigned system to be a successful System Engineer?
Technical Document
Page 41 of 42
73TD-0ZZ03
Revision 9.0
Technical Document
Page 42 of 42

System Engineering Handbook R91 - 1

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

System Engineering Handbook R91 - 1

Hochgeladen von

Copyright:

Verfügbare Formate

SYSTEM ENGINEERING HANDBOOK

Glover, John J (Z30799) _________________________________________

_________________________________________ Owner Approval

Sweeney, Kevin M (Z99575)