ML20151T502

Project Implementation Plan, Ngg Yr 2000 Readiness Program, Rev 2

ML20151T502
Person / Time
Site:	Brunswick
Issue date:	08/05/1998
From:	German R, Northeim E CAROLINA POWER & LIGHT CO.
To:
Shared Package
ML20151T494	List: BSEP-98-0181, Forwards Rev 2 to Project Implementation Plan, Ngg Yr 2000 Readiness Program, Per 980901 Telcon Request.Info Will Be Used by NRC to Support pre-visit Activities Performed in Preparation for Yr 2000 Readiness Audit ML20151T502
References
NUDOCS 9809100018
Download: ML20151T502 (96)

Text

_ . _ _ . . . _ . , _ _ _ _ _ . _ . . _ _ . . _ _ _ _ _ . . _ . . _ . . _ . _ . . . . _ . . . . _ _ . _ _ _ _ _ _ _ _ _ _ _ _ . . _ _ - - .

NGG Year 2000 Readiness Program 1

l Project implementation Plan l

Title:

NGG Year 2000 Readiness Program Revision No.: 2 i Date: 08/05/1998 '

l l

l Y. 8hl/ffA Approval: Eric M. Northfim - Proje3Nanager Dats A.L Approval: Randall G. G5rman ' Project Sponsor dskt Date '

CP&L '

l l

9809100018 980904 l PDR ADOCK 05000324 P PDR i CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98 I

NGG Ysar 2000 Readiness Program 2 TABLE OF CONTENTS SECTION 1.0 - PURPOSE AND SCOPE 4 SECTION 2.0 - MANAGEMENT AWARENESS 4 2.1 - Project Background 4 2.2 - Objectives 8 2.3 - Benefits 8 2.4 - Key Assumptions 8 2.5 - Benchmarking and Peer Review 8 SECTION 3.0 - DEFINITIONS 10 SECTION 4.0 - PROJECT DESCRIPTION 11

, 4.1 - Study Phase 11 4.2 - Implementation Phase 12 4.3 - Contingency Planning 14 4.4 - Sponsorship 14 4.5 - Project Leadership 14 4.6 - Project Organization / Interfaces 15 SECTION 5.0 - COMPLIANCE CRITERIA 16 '

, 5.1 - TechnicalCriteria 16 5.2 - Testing Guidelines 16 5.3 - Standard Contract Language 16 SECTION 6.0 - PROJECT CONTROLS 17 6.1 - Project Schedule 17 6.2 - Project Cost 18 6.3 - Performance Reporting 18 SECTION 7.0 - QUALITY ASSURANCE 19 i l

7.1 - Project Management Quality Assurance 19 l 7.2 - Implementation Quality Assurance 19  ;

7.3 - Assessments 19 SECTION 8.0 - DOCUMENTATION 20 8.1 - QA Records 20 8.2 - Project Records 20 SECTION 9.0 - PROGRAM REVISIONS 21 CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Rsadinsss Program 3 APPENDICES A Communications Plan 22 B Project Scope Assessment Data Sheet 23 C Inventory and Initial Assessment Business Unit Action Plan Form 24 D Detailed Assessment /Remediation Flow Chart 25 E Certification Package 26 F Technical Criteria 27 G Testing Guidelines 28 H Standard Contract Language 29 l

~

i I

i i

1 I

i l

f i

e CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Rsadiness Program 4 1.0 - PURPOSE AND SCOPE The purpose of this implementation plan is to establish the scope and controls of the Carolina Power & Light Company, Nuclear Generation Group, Year 2000 Readiness Program. This plan meets the intent of NEl/NUSMG 97-07 " Nuclear Utility Year 2000 Readiness" by incorporating the major elements of the " Imp!smentation Plan" defined therein. This implementation plan is intended to be a living document that is revised as the project matures from the study phase through the implementation phase.

' Portions of the " Management Plan" defined by NEl/NUSMG 97-07 have been placed within the Project implementation Plan for clarity. Carolina Power & Light Company's Phased Project Authorization Form, defined within procedure ADM-NGGC-0102, provides the remaining portions of the " Management Plan". Facility and senior management approvals for the project scope, schedule, and costs are documented in the Phased Project Authorization Form for each phase.

The scope of the NGG Year 2000 Readiness Program includes potentially affected software applications, computer systems and hardware, and embedded plant systems / components whose failure due to a Y2K problem would prevent the pedormance of the safety function of a structure, system or component or would degrade, impair, or prevent operability of the nuclear facility. It is intended to supplement and use existing procedures used for software quality. l control, configuration management, and problem reporting.

2.0 MANAGEMENT AWARENESS l 2.1 Project Background The essence of the Year 2000 problem is based on the historically common computer q

. programming practice of representing the year component of a date with only the last two digits '

of the year. This can occur in all types of programmable technologies such as computer ,

systems, hardware and software; telecommunications systems; automated devices such as programmable meters and elevators. When these systems begin processing dates that i represent both the 20* century (19xx) and the 21" century (20xx) various and uncertain results can be expected if the system is not Year 2000 compliant. At one extreme, the computation involving these dates may fall completely, providing users an obvious error indication. At the  ?

other axtreme the computation using these dates may produce incorrect results in such a manner such that no error indication is noticed and the incorrect process continues undetected.  !

The significance of the condition is directly related to the importance of the particular system in which these computations occur.

l

)

I c- .-

CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04.98 j l

I

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

I i l

' NGG Year 2000 Readiness Program 5

) --Another aspect of this same problem is the method in which data is stored. When the year t.

d component of a date is stored in two digit format, the interpretive ability of the processing

• element to correctly distinguish between 20* century detes and 21" century dates becomes the issue. Some of the different types of problems can be defined as follows:

. Century ambiguity When the century rolls over the "00" year date would be seen as 1900 rather than 2000 since the 19 is generally appended as hard code to any year date field.

ll Mathematical error ("00* seen as smaller than "99" rather than larger)

Any date calculations would be in error since "00" is not seen as larger than "99".

[ e Date offset (time interval from a base time)

.E 'Many systems use their creation date as a base time and all clock functions are calculated in relation to that date. For example, time is based on 1:1:1/1/1985 +

1 (smallest unit).

i This problem presented itself when some testers decided to roll back their

computer clock to 1958 - a time when leap years, planet relationships, etc. were i

the same as they will be in the year 2000. The problem was that the system did i 4

not know what to do with the year 1958 because it's own " birth" was not until

1985. In some cases the system defaulted to 1985. In other cases the system

[ just stopped. l I To extrapolate from this lesson, a roll over to "00" perceived as 1900 could cause

. the same results since 1900 is also before the " birth" of the system.

e inconsistent semantics (one system 1900, other 2000)

.* Extended semantics ("not to expire" )

This coding is used for licensing purposes and will make a product inaccessible at a specified point in time. Rolling a date forward during testing could potentially invalidate a hard key security license.

. There are also some other dates that could potentially become a problem:

i

, 9/9/99 - 9's are often used in coding to be a default. How will software deal with

! seeing a series of 9's in the date field?

i

Leap year - Year 2000 is a leap year on the century. Generally the century year i

drops February 29 to bring time back in line, however on the millennium this day is kept. Has this been taken into account by the system developers? What is i the impact on the " day of the week".  ;

4 o

s .ar S w .. m .>

!- CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98

i 4

ji NGG Year 2000 Raadinsss Program 6

'Although databases are a problem, they are just the tip of a very large iceberg. The reality is that any automated process or component that depends on a date calculation to perform a l . function could have a problem.

i

' Date programming can be found in software applications and firmware, that is, process 3-computing systems and embedded systems / components. Because the Year 2000 problem has i

the potential to impact thousands of applications and components, CP&L has initiated a corporate wide effort to inventory, assess, and fix those areas important to the business.

j The business case includes the ability to properly generate and distribute electricity without

• inadvertent shutdowns of plants or the grid. In addition, revenues can be severely hampered by the inability to process electricity bills and payments. Also, CP&L could very well be sued over issues arising from Year 2000. Estimates from the money in legal suits nationwide have been estimated as high as one trillion dollart.

i j

This problem represents a potentially significant impact on nuclear plant operations wherever ,

digital devices such as computers, communications equipment and embedded microprocessor  !

based components are used. Failures in these components could lead to inadvertent safety i system actuation, plant trips, or loss of control room indicators. In this light, Year 2000 is much  !

mom than a traditional information Technology problem. It is a potential business problem  ;

j r impacting all aspects of the Company. Some examples of nuclear systems at risk are: '

Plant Process Computers Dosimeters / Readers Calibration Equipment ERFIS Programmable Logic Controllers Chart Recorders Plant Simulators EPROMS Event Recorders i

i Security Systems l Meters Performance Monitoring i i Relays Engineering Analysis Applications Bar Code Systems p Variable Speed Pumps Instrumentation Laboratory Devices j

in addition, there are potential Year 2000 risks associated with the spare parts inventories and on-going vendor replenishment processes related to these inventories. Two questions have to be: (1) Are my current spares Year 2000 compliant ? (2) is the vendor supplying Year 2000 compliant materials? These kinds of issues demonstrate that the scope of the Year 2000 compliance extends beyond the normal boundaries of plant operations. Contractual and legal resources will need to be brought into the project as a result of this general extemal supplier i situation.

The NRC has directed the industry to demonstrate that the necessary actions to identify,

. correct, and implement needed changes are being taken to ensure continued safe operation.

As a first step, the NRC published Information Notice 96-70 informing licensees of the Year l 2000 problem. In September,1997, the NRC iscued SECY 97 213 which further defined the I NRC expectations that licensees have an active Year 2000 program. The NRC issued Generic l

l

Letter 98-01 on May 11,1998 to request official information on each utility's Year 2000 t

program. This generic letter requires that licensees certify that each facility is Y2K Ready by 4-July 1,1999, Any exceptions are to be provided in detail with schedule completion dates. '

i i- Due to the project focus on high and medium priority items deemed as critical and important to i the business, some Year 2000 work will be deferred for consideration after January,2000.

Those related efforts will be justified on their own business merits at that time and funded j accordingly.

a CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Readinsss Program i l

l The Nuclear Energy Institute (NEI) and Nuclear Utilities Software Management Group (NUSMG) jointly teamed to produce NEl/NUSMG 97-07," Nuclear Utility Year 2000 Readiness" which contains a framework for a Year 2000 program. Through interface with NEl, NUSMG, and the training provided by the task force that developed the document, CP&L has determined that the program concepts are applicable to the NGG Year 2000 Readiness Program.

l l

l l

l l

l l

"- wu CONFIDENTIAL INFORMATION . FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Rsadiness Program 8 2.2 Objectives The mair' project objectives are qualitative in nature as follows:

Minimize the economic impact of the Year 2000 evaluation and compliance activities on NGG operations.

Demonstrate reasonable assurance that Year 2000 problems will not adversely impact plant safety or operation.

Maintain a high degree of regu'atory and public confidence in the safety of CP&L's nuclear plants.

• Effectively manage the risks associated with the project.

Assure that Year 2000 change activities are fully identified and monitored to completion l

2.3 Benefits t The benefits expected to be gained by the project include:

CP&L's competitive position in the business will remain intact, unaffected by the change activities related to Year 2000 compliance.

. Position NGG to meet the anticipated regulatory requirements associated with Year 2000 l compliance.

2.4 Key Assumptions Several key assumptions are essential to the viability of the project and include:

Management approval to initiate the project in 1997 and reallocate existing budgeted CP&L

. labor

. Availability of required in-house resources to support project activities e Establishment of project ownership / accountability at NGG line management levels i e Strong, sustained, and visible senior management support

. Adherence to project milestones I l

2.5 Benchmarking and Peer Review I Since the Year 2000 effort is in a developing state with few definitive standards, benchmarking within the industry becomes increasingly important. Efforts with outside entitles will be established, as necessary:  !

CDSV The Carolina Power & Light strategic alliance with Duke Energy, South Carolina Electric & Gas, and Virginia Power nuclear organizations is an integral part of this project. The CDSV Nuclear Exchange Program established through this alliance uses a team concept to improve safety, cost, and reliability by leveraging collective skills and resources. The " Focus Teams" are directed by a steering committee consisting of one management representative from each member utility. Executive sponsors monitor the activities of the program to assure added value.

A Year 2000 issues Focus Team was endorsed by the CDSV Steering Committee on July 23, i 1997. The team's current initiatives are embodiM in its Implementation Plan. The plan targets  !

,m ,. --

CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Rsadintss Program 9

compliance testing, industry focus, regulatory risk management, and project quality as potential sources of benefit. These initiatives are summarized as follows:

4 The Year 2000 efforts of each utility must provide reasonable assurance that the Year 2000 event will not adversely impact plant safety. The team will establish consensus methodologies for prioritization, assessment, and testing activities that incorporate the best practices from each utility.

Testing costs to assess or verify Year 2000 compliance may represent a significant portion of project costs. The team will share inventories of affected devices to determine where common testing can be performed to reduce these costs.

Several industry organizations are working to provide Year 2000 solutions to the industry.

The team plans to establish consensus positions on issues that impact the industry in an effort to influence the outcome of these efforts and encourage teamwork among industry organizations.

NEl

~

Participation with NEl should be pursued for the development of Y2K program guidance, and industry discussion with the NRC.

The CDSV Focus Team, through its Duke Energy representative, participated in the NEl Year 2000 issues Task Force that developed NEl/NUSMG 97-07. In addition, this task force is developing an addendum to include contingency planning.

CP&L participated on the NEl Task Force for a generic industry response to Generic Letter 98-01.

EPRI EPRI has developed a program for industry sharing of information in the area of embedded systems. CPAL has elected to participate in this effort by attending the periodic workshops and participation on various vendor teams. Sharing of the CP&L inventory will be handled by the CP&L Corporate Y2K Program Office.

Owners Groups The BWROG and WOG have developed forums for sharing of costs to perform assessment and/or testing for Y2K. CP&L has entered into generic funding with the BWROG for the initial  ;

assessment of GE-NE shared components. Further consideration will be given to cafeteria i style funding of assessments and testing with the BWROG and WOG, as deemed appropriate.

~

CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

.NGG Year 2000 Readinzss Program 10 3.0 DEFINITIONS The definitions defined herein have been adopted from NEl/NUSMG 97-07.

Year 2000 (Y2K)- A term used to describe a set of date related problems that may be experienced by a software system or application. These problems include: not representing the year properly, recognizing that the year 2000 is a leap year, and improper date calculations.

Y2K Compliant - Computer systems or applications that accurately process date/ time data (including but not limited to, calculating, comparing, and sequencing) from, into and between

the twentieth and twenty-first centuries, the years 1999 and 2000, and leap-year calculations.

Y2K Ready - A computer system or application that has been determined to be suitable for continued use into the year 2000 even though the computer system or application is not fully

Y2K Compliant.

Validation - A process that evaluates the functional characteristics of the software, and certifies the achievement of acceptable comparisons with Objective Evidence.

Objective Evidence - Any statement of fact, Information, or record, either quantitative, pertaining

'o the quality of an item or service based on observations, measurements, or tests that can be verified.

Remediation - Remediation is the process of retiring, replacing, or modifying software or devices that are to be retained in service, but have been determined to be affected by the Y2K problem.

4 l

CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

~

d 4

NGG Year 2000 Readiness Program 11 4

4.0 PROJECT DESCRIPTION i

In accordance with procedure ADM-NGGC-0102, the Year 2000 Readiness Program will be set

!~ up in the phased format, those being study and implementation. The design phase was

. eliminated in order to work remediation efforts concurrent with continuing detailed assessment j

efforts. This is required due to time factors associated with the project end date.

i 4.1 Study Phase i The Study will contain the elements of Awareness and initial Assessment as defined by

[ NEI/NUSMG 97-07 and will cover the following areas:

A

, A communication plan will be developed to foster an awareness of the Year 2000 issues to

[ company management and employees including, as a minimum:  !

l e Briefing and buy-in of NGG management

e Education of the general population of NGG personnel e Trai,ning of personnel performing inventory and assessment e Year 2000 team communication methods l

e Reporting of team progress to NGG management J l *- Interface requirements with the CP&L Corporate Year 2000 effort

[ . Establishing contacts with outside industry for benchmarking I e Establishing contacts with regulatory agencies l; e Establishing compliance criteria for external software /firmware vendors 1

A database inventory will be developed including potentially impacted applications, computer  !

j systems and hardware, and embedded plant systems / components:

e The database will utilize Microsoft Access, or equivalent, as the platform and should include

sufficient data fields to allow for categorization, classification, prioritization, cost estimation,

test planning, and remediation tracking.

i . The database will be able to supply the appropriate information to interface with the CP&L

. Corporate Database, currently in Microsoft Excel format.

e Data will be loaded for applications, computer systems and hardware, and embedded plant l

systems / components Personnel familiar with each business unit area will be utilized to provide the inventory of l' potentially affected items by utilizing the Year 2000 Project Scope Assessment Data Sheet

j. (Appendix B) or similar. For example, system engineers should review permanent plant j equipment for which they are responsible. Categorization of like items can be used to simplify future assessment efforts.  ;

• For embedded plant systems / components, a key word search is to be performed on the '

i plant Equipment Data Base System (EDBS) and the Plant Operating Manual (POM) to

4. . provide additional confidence that the inventory is complete.

I e For software applications, the inventory developed for the software quality assurance i manual shall be utilized, as necessary, to provide additional confidence that the applications j inventory is complete.

4 4

CONFl0ENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98 L

4 4 t 1

NGG Year 2000 Readiness Program 12 l

Vendor correspondence criteria will be established for requesting Year 2000 compliance verification:

i Personnel involved in the inventory are encouraged to contact vendors to discuss Year 2000 testing, design of the system, etc.

{ e

• Official letters requesting vendor compliance certification should be directed through CP&L Corporate Purchasing. Official contract language will be developed by Corporate Purchasing.

Technical compliance criteria shall be established for use internally and with vendors.

l k ' Business unit action plans (Appendix C) will be developed to document the decision analyses for the scope of items requiring detailed assessment:

i Risk assessment, i.e. the consequences of failure will be utilized to prioritize each j inventoried item as high, medium, low, or replaced / obsolete.

1 High (1)

• Nuclear or personnel safety, regulatory requirement.

loss of plant capacity

Medium -(2) Significantly impair the ability to execute major business j

functions, cause unavailability of Maintenance Rule i systems, create operator workarounds j

. Low (3) Cause inconvenience but would not impair ability to j perform major business or system functions T

Rept/Obs (4) Will be replaced or become obsolete before Y2K problems are encountered Documentation of each decision should be provided in a retrievable format. This may be

} needed to defend due diligence.

l .

. Business unit management agreements will be obtained to ensure line management

ownership.

4.2 Implementation Phase i

!- The implementation phase will contain the elements of Detailed Assessment, Testing, r Remediation, and Validation as defined by NEl/NUSMG 97-07. The implementation phase will i

produce a certification that the application, computer system and hardware, or embedded plant

system / component is either Year 2000 Ready or Year 2000 Compliant.

t.

A detailed assessment will be performed for high and medium privrity items. Business units are encouraged to perform detailed assessments for low priority items as time and resources allow.

j The purpose of detailed assessment is to obtain sufficient information to evaluate whether remediation efforts are required and document the bases for decision making. The goal is j reached through collecting objective evidence, i.e. any statement of fact, information, or record, i either quantitative, pertaining to the quality of an item or service based on observations, j measurements, or tests that can be verified.

b f .

f CONFIDENTIAC INFORMATION FOR CP&L USE ONLY 08/04/98

. _ . _ _ , . . _ . _ _ , . ..y.- -.,,w -., -

i-i

, NGG Year 2000 Readiness Program 13 j

1

.i A detailed assecsment includes the following areas, as appropnate, to the item being assessed:

l e interface Evaluation - Evaluation of the interfaces, both intemal and external, for passing j dato and time related data.

e I

i Vendor Evaluation - Evaluation of available manufacturer / developer information, such as contracts, correspondence, teleconference notes, Internet listings, vendor manuals, vendor j user groups, etc.:

i

!' e:

Test Plana /Results - Test procedures should be developed to determine if a Y2K proble,,n

exists._ Testing criteria for dates should follow the CP&L Corporate Testing Guideline (Appendix G). If no test is performed, justification should be provided as to why it was not j required.

i

! e Soare Parts Evaluation - Spare parts in inventory should be reviewed to ensure that Y2K problems are not recurrent after remediation efforts are completed.

l . Trainina Systems Evaluation - Some systems have duplicates in the plant simulators or i training facilities. The detailed assessment should consider the impact to simulator

{ components for existing equipment and upgrades.

l f .

Subiect Matter Expert Review - The evaluator should utilize, as appropriate, any other j relevant information obtained through walk down, review of embedded microchips, review of f source code, etc.

(

Results - The detailed assessment should conclude the overall results of the detailed  !

assessment and provide the remediation recommendations and justification.

L After completion of the detailed assessment, the remediation recommendations are formed into

' a remediation plan for implementation. Notification will be provided to and feedback will be received from affected parties. The remediation plan should include a review of the original i scope, cost, and schedule estimates with additional management approvals as required by procedures. Remediation is the process of retiring, replacing, or modifying software or devices that are to be retained in service, but have been determined to be affected by the Y2K problem.

l After the remediation is completed, validation testing is required. This is no different than any other modification or upgrade to software or hardware. Existing plant procedures are to be

[ utilized for all modifications and upgrades.

l 1 I

. The final documentation of the detailed assessment and remediation,if required, will be

, developed using the Year 2000 Certification Package (Appendix E). Upon completion of the l Year 2000 Certification Package, each item will be designated as either Y2K Compliant or Y2K l

Ready. j i

The Year 2000 Certification Packages provide the Y2K readiness documentation for

systems / components / structures 'and software applications controiied by NGG business units.

, Interfaces with other organizations (electric utilities, telecommunications utilities, suppliers, 1- emergency services, govemment offices, etc.) outside the NGG should be reviewed to ensure i- that the organization institutes an appropriate Y2K effort. This function is to be handled through 1 the CP&L Corporate Y2K program office by utilization of the Corporate Purchasing Vendor

} Management Program.

. CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98 1

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

NGG Year 2000 Readiness Program 14 4.3 Contingency Planning  !

Contingency planning should be viewed as a layered approach. Y2K issues begin with the l

l individual inventoried items, which are within a larger system, which are within the plant boundaries, and out to the grid. Each area has its own unique method of proper contingency planning. Although a detailed plan for contingency planning has not yet been developed, the following items should be included.  !

Individual inventoried items will be assessed during the detailed assessment and l

remediation efforts performed. In some cases, workarounds will be used rather than I achieving full Y2K compliance. These workarounds are the contingency planning efforts for individualitems. . These contingencies should be documented within the Year 2000 Certification Package  !

Systems are comprised of individual items and sometimes include hardware and software.

Even though they may each be assessed individually, the interactions may not be able to be fully tested, in these cases, contingency plans may be required to understand potential failure scenarios and provide for support. These contingencies should be documented within the Year 2000 Certification Package.

The nuclear plants are required to provide contingency plans for abnormal and emergency conditions, including operations procedures and the emergency plan. A review of these existing abnormal and emergency plans should be performed for Y2K caused scenarios.

Interactions within the different corporate departments could cause perturbations on the I plant, for example, switchyard breakers and telecommunications. A review of the Year 2000 Certification Packages should be performed for items in those departments that can affect the nuclear plants.

Extemal suppliers of critical materials such as chemicals, fuel, oil, potable water for fire suppression, etc. could have an impact on the ability to continue to operate. Contingency plans should be developed for critical areas of the supply chain.

i e i Interactions with other grid partners could cause unanticipated shut down of the nuclear plants due to low grid voltages. A plan should be developed with SERC on how to handle '

grid issues.

4.4 Sponsorship I A sponsor will be established for the project and should be selected from the operating plant  !

sites. This establishes the need for lino management support at the business unit level and to clearly dictate that the Year 2000 issue is not just an Information Technology problem.

4.5 Project Leadership A full time NGG project manager will be utilized to coordinate the overall project scope, schedules, and budgets and also provide consistency between BNP, HNP, RNP, NED, and OESD. In addition, the NGG project manager will be the focal point for interfacing with the overall CP&L Corporate Year 2000 project leader and performing as the intarface with external groups to ensure adequate benchmarking.

CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Readiness Program 15 4.6 Project Organization / Interfaces

, The NGG Year 2000 Readiness Program requires a significant commitment of people

)

knowledgeable of the commitments, strategic intent, culture, vulnerabilities, and capabilities of  ;

i the utility. Therefore, the project will utilize existing CP&L resources qualified within the ,

affected business units to inventory and assess the potentialimpacts. Staff augmentation  ;

and/or contractor consultation may be utilized, however, should be under the direction of the l business units and their qualification programs. The core project team organization is I structured such that the major functional organizations represented by each nuclear plant have l distinct lead personnel in place to support their specific scope. Each plant will have a designated Project Lead providing day to day guidance and direction to the functional q

, organization's Year 2000 compliance efforts Each organization will require subject matter experts to support their Year 2000 compliance activities. A conceptual organization model is j 4

shown below. '

i L

,i Team Members HNP Busmose Systems Prgect j Plant Systems lead Erdneenna 2

Team , NGO Members: RNP Manaoement Busness Systems Peqect -

Power Pterit Systems lead Operanons Enaneenna Prgect i ,

Coordmator Team Members SNP

. Busnese Systems Project ITSO Fnanciai Plant Systems lead Corporale

' Services Enanoenna Coordinator Prqect Coordnetor Team OESOr Members NED Busmoss Systems Proiset

. Energy Encaneenna lead De#very

• Project

.' Coorenator \

NGG ,

Prgect l Coorenator

• e 4

CONFIDENTIAL INFORMATION . FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Readiness Program 16 5.0 COMPLlANCE CRITERIA Specific compliance criteria are necessary to assure the compliance requirements are satisfied.

The criteria consist of unique assessment or test attributes that the applications and/or equipment must meet and relevant acceptance criteria. Three compliance documents have been developed under the CP&L Corporate Y2K Program to ensure common compliance requirements.

5.1 Technical Criteria An application or equipment is considered century compliant if it meets the General Integrity and Date Integrity criteria and either the Explicit or implicit century criterion that follow:

e No value for the current date will cause interruptions in normal operation (General Integrity),

. All manipulations of calendar-related data (dates, duration, day of week, etc.) will produce desired results for all valid date values within the application domain (Date Integrity),

. Date elements in interfaces and data storage permit specifying century to eliminate date ambiguity (Explicit Century), and

. For any date element represented without century, the correct century is unambiguous for all manipulations involving that element (Implicit Century).

. Refer to Appendix F for the complete technical document.

5.2 Testing Guidelines Standards for testing are to be utilized so that common acceptance of the results can be obtained. Under certain circumstances, only a subset of the date tests are required to confirm Y2K Readiness, however, justification should be provided for the deviation.

Refer to Appendix G for the complete testing guideline document.

5.3 Standard Contract Language Standards for testing performed by vendors to meet contractual sequirements are to be utilized so that common acceptance of the results can be obtained. Under certain circumstances, only a subset of the date tests are required to confirm Y2K Readiness, however, justification should be provided for the deviation.

Refer to Appendix H for the complete contract warranty documents.

6" .V^ b-CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

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

4 NGG Year 2000 Readiness Program 19 i

7.0 QUALITY ASSURANCE l The NGG Year 2000 Readiness Program activities will comply with all requirements of the ll CP&L quality assurance program. The reviews, assessments, and technical evaluations <

performed under this project shall meet all applicable requirements of the Nuclear Generation 4

. Group and Plant Operating Manual Procedures. The use of these procedures incorporates appropriate regulatory and business considerations such as reportability, operability, unreviewed safety questions, etc. '

Specification of quality requirements for replacement systems, equipment, or devices used to remedy non-compliant items should be consistent with existing CP&L standards applied commensurate with the item's importance to safety.

7.1 Project Management Quality Assurance Project management standards shall be utilized as established within procedures:

. ADM NGGC-0102," Project Review and Authorization"

. ADM-NGGC-0103, " Project Management" 7.2 Implementation Quality Assurance Software upgrades shall follow the requirements of software control procedures:

. CSP-NGGC-2501," Control and use of Engineering Software"

• CSP-NGGC-2502," Software Quality Assurance Configuration Control and Life Cycle" e CSP-NGGC-2503, " Nuclear Fuels Management & Safety Analysis Computer Software Quality Control" Permanent plant equipment testing shall follow established procedures for procedure development and use including full procedures, partial procedures, troubleshooting, etc.

Permanent plant equipment modifications shall utilize procedure EGR-NGGC-0005,

" Engineering Service Requests" Y2K noncompliance verified through testing or evaluation shall be documented using existing ,

procedures for Condition Reporting to allow for applicable reporting requirements.

7.3 Assessments Periodic assessments should be performed to ensure consistency with program requirements in >

accordance with established site and corporate procedures. This should include self assessments and assessments by independent organizations such as the Performance Evaluation Section (PES) and the Nuclear Assassment Section (NAS). i l

l l

l CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98 l 1

i NGG Year 2000 Readiness Program 20 8.0 DOCUMENTATION 8.1 QA Records Documentation developed as OA Records for this project shall be retained in plant records as required by applicable procedures.

8.2 Project Records The project will develop many other records which may not qualify as OA Records, however, should be maintained for review during and after the project is completed. Items to consider include as a minimum:

. Project plans

. Schedules

. Cost reports e inventory listing *

. Inventory Questionnaire Forms *

. Y2K Certifications *

• Letters to vendors *

• Vendor response letters *

• Assessment reports

• l

• Consideration should be given to store as vital records. l 1

I i

CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

NGG Year 2000 Readiness Program 21 9.0 PROGRAM REVISIONS i Revision 1 4

. Added references to NRC Generic Letter 98-01.

. Added information on interfaces with NEl, EPRI, BWROG, and WOG.

. Clarified risk assessment use for setting prioritization of items.

. Removed design phase and updated implementation phase details.

. Added new section on contingency planning.

. Added new sections for testing guidelines and warranty language.

. Updated the level 1 project schedule to reflect current plan.

. Updated project cost data and current FAIM project numbers.

. Added new section for assessments.

. Added appendices for various forms and checklists that have been developed since the initial issue.

. General wording updates to reflect current status.

Revision 2

. Changed program name to NGG Year 2000 Readiness Program.

. Added scope to purpose section to clarify the items included.

. Added requirement for remediation plan to inc!ude a review of the original estimates and notification of affected parties.

. Added section to discuss the CP&L Vendor Management Program for contacting external organizations.

. Clarified the project organization for utilizing resources knowledgeable and qualified in CP&L's processes.

. Added new requirement for independent assersments of the program.

2

. Clarified the use of categorization data to simplify assessment efforts.

l 4

l 4

i CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98

1 1

NGG Year 2000 Readiness Program 22 i

1 4

APPENDIX A

. COMMUNICATIONS PLAN i

t A4 J

)

4 i

J J

CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98 i

l NGG Year 2000 Compliance Program 1

l 1 4

i 1

I r

Project Communications Plan i

4 NGG Year 2000 Compliance Program Revision No.: 0

Date: 12/02/97 a

aa l

1 i

l "Y

Approval: Eric M. Northefm rojectRamrg'er lll2/47 Date

) h Cc- --

Approval: Randall G. German - Project Sponsor t2/7/97 '

Date' l

l i

l l i

4 4

1 i l l

i CP&L -

i i

4

CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 12/02/97

i NGG Year 2000 Compliance Prograrn 2 i l

1.0 INTRODUCTION

The purpose of this Communicathns Plan is to provide the actions necessary to adequately I inform NGG management and empioyees, interface with the corporate Year 2000 effort, and l

interface with extemal organizations.

l 1

Communications are ar. essential part of the Year 2000 Compliance Program since the project

! covers such a diverse scope including software applications, process computer systems, and j embedded systems / components. In addition, activities must occur at all three of the nuclear sites, in downtown nuclear support organizations, with the CP&L corporate Year 2000 organization and with extemal organizations such as the CDSV, NEl, NUSMG, and the NRC.

I l

i 2.0 NUCLEAR GENERATION GROUP ACTIONS  !

i

2.1 Briefing and buy-in of NGG management i

4 2.1.1 Prepare and deliver a presentation to the NGG Executive Vice President and the NGG #'

department heads

{ Status: Completed on 8/27M7 at the NGG Department Manager Meeting i

4 2.1.2 Prepare a Study Phase project authorization and present to BNP, HNP, and RNP Plant j Review Groups

Status

RNP- completed on 10/1M7 i HNP- completed on 10/20/97 BNP- completed on 11/4/97

2.1.3 Sustain management support and buy-in through a combination of status updates, department management meetings, and future PRG meetings as necessary Status: Open 2.2 Education of the general population of NGG personnel 2.2.1 Prepare a communiqu6 for inclusion in the departmental newsletters Status: Communiqu4 developed and sent to depat1 ment editors on 11/3/97.

HNP - completed with 11/1097 issue of Harris Notebook BNP - completed with 11/19/97 issue of Brunswick Today RNP - completed with 11/13t97 issue of Robinson Review OESD - completed with December issue of Focal Point g t+

CONFIDENTIAL INFORMATION . FOR CP&L USE ONLY 12/02/97

l NGG Year 2000 Compliance Program '

3 4

2.2.2 Provide periodic updates on the Year 2000 Compliance Program through the l departmental newsletters >

Status: Open  !

2.3 Training of personnel performing inventory and assessment 4

' L 2.3.1 Prepare a set of training notes and provide to engineering and subject matter experts j Status: HNP - Completed. Inventory was startedpriorto the project study, therefore, i

training notes were provided on 7/2&97 with the inventory question'naire RNP - Completed. Training notes prepared on 10/29/97 andissued 11/6/97 BNP - Completed. Training notes prepared on 11/5S7 and issued 11/12/97 1 2.3.2 Distribute Year 2000 Technical Criteria document to applicable team members.

Status: Open 2.3.3 ' Distribute Year 2000 Testing Criteria document to applicable team members .

Status: Open 2.4 Year 2000 team communications 2.4.1 Utilize electronic mail as the main form of communication 1 Status: Open. Historicalfiles set up on Microsoft Exchange 2.4.2 Schedule videoconferences for the team members on an as needed basis  !

Status: Open. First conference held 10f29/97 2.5 Reporting of team progrens to NGG management 2.5.1 Develop a standard project report and frequency Status: Open 1

CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 12/02/97

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

1 NGG Year 2000 Compliance Program 4 4 I

4 3.0 CORPORATE YEAR 2000 INTERFACE ACTIONS i

3.1 Provide periodic status updates to the CP&L Year 2000 manager Status: Open. Group coordinatormeetings being held approximately monthly Project reports updated biweekly 3.2 Provide periodic uploads to the CP&L common listing of applications and devices Status: Open 3.3 Provide email postings of important information to provide easy access to all personnel Status: Open. Microsoft Exchange site added underPublic Folders /AllPublic

} Folders / Corporate / Year 2000 2

4.0 EXTERNAL INTERFACE ACTIONS o

! 4.1 Establish contacts with outside industry for benchmarking of program e

4.1.1 Establish CDSV Year 2000 subcommittee 4

i Status: Completed. Meetings held on a rotating basis approximately monthly. Website a

developed for meeting minutes, action items, etc.

4.1.2 Establish contacts with NEl

(' ' Status: Completed. Northeim/Grosch attended NEl/NUSMG ' Nuclear Utility Year 2000 Readiness" program document training 11/14/97. CP&L contacts added to the NEImonitoredlist server.

t 4.1.3 Establish contacts with NUSMG Status: Completed. Cynthia BroadweIInamed as the CP&L contact point forNUSMG.

4.1.4 Establish contacts with EPRI Staus: Open. Contacts made with Joe Weiss of EPRI. CP&L undecided as to

whether tojoin the EPRI Year 2000 effort.

}_ 4.2 Establish interface with government agencies

4.2.1 Provide project information as needed to NRC 1

Status: Open. Expect officialinformation to be requiredin early 1998 via generic letter response.

F ANCiricMTI AI INropueTIAM . CAO 0011 4 ICC ANI V 17#17/Q7

NGG Year 2000 Comphance Program 5

4.2.2 Provide project impact statements to FERC Status: Open 4.3 Establish compliance criteria for external softwarelfirmware vendors 4.3.1 De,. .' lop specific language for new contracts to ensure vendor requirement to meet Year 2000 aompliance Status:

' Completed. Language fornew contracts developed by corporate purchasing.

Posted on Exchange /Public FolderWAll Public Folders /CorporataNear 2000/

Siandard Contract Language..

4.3.2 Develop vendor compliance certification language for existing contacts Status:

Completed. Language for existing contracts developed by corporate purchasing.

Posted on Exchange /Public Folders /All Public Folders /CorporateNear 2000/

Standard Contract Language.

aa

-1

.q l

l 4

CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 12/02/97

NGG Year 2000 Readiness Program 23 T

APPENDIX B PROJECT SCOPE ASSESSMENT DATA SHEET I

i l

.i i

CONFIDENTIAL INFORMATION . FOR CP&L USE ONLY 08/04/98

Year 2000 Project Scope Assessment Data Sheet Instructions: Complete this form for each plant system for which you are responsible. If your assessment of the system results in a Yes answer to any of the questions. complete an Assessment Data Sheet for each component you suspect may pose a Year 2000 problem. Please answer all applicable questions. Limit the " Uncertain" responses. Provide additional information for clanfication.

Type (Check One) O Plant Equipment (in EDBS) Complete Sectwn / and 2 and Questwns / /3 0 flardware (Not in EDBS) . Complete Sectwn i and Questwns i - 13 0 Firmware (Not in EDBS} . Complete Section I and Quesnons I .13 0 Software . Complete Section I and 3 and Questions 6 13 Sectwn 1. Generalinformatwn item Narne item Description.

Owner Name: CP&L Part # Quantity:

Vendor / Manufacturer Model Number Sectwn 2. Plant Equupment EDBS Name: PLANT UNIT SYSTEM EQUIP SPEC.lD Sectwn 3. Software Program Name Version is there a Maint Agreement? Y / N Yearly Cost S Program Runs on: (Check One) W'ho Supports the Software:(Check One)

Mainframe Q vendor 0 Server O ITSD 0 PC 0 Owner O Process Controller O Not Supported 0 Microprocessor 0 Survey Questions Yes No Uncertain I. Does the equipment / application contain a microprocessor / processor board?

2. Does the equipment / application have rtrmware (i e. ROM. PROM. EPROM. EEPROM)?

3. Does the equipmenvapplication have an intelligent controller (i.e. perform integration and/or derivative function)?

4. Does the equipment / application generase an output with a date or tirne stamp?

5. Does the equipment / component require manual entry of date and time?

6. Does the equipment / component perform a date calculation?

7. Is the equipment / application menu configurable?

8. Does the equipment / application have a clock function?

9. Does the system contain equipment which utilizes an operating system. software, or rirm vare?

10. Is there a modification or change planned for this system that could change some of the previous answers?

I 1. Can tesnns of this equipment / application be done on-line?

12. Would failure of this item impact the operation of the plant?

13. Does system inwrface with other systems (by passing / receiving a date) ?

If yes, list related system on comment sheet.

1 I

I l

Conaments l Please provide additional infornuuon that will assist with the assessment of your system / program. l SystemT.ngineer/ Owner-Print Signature Date a

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

NGG Year 2000 Readiness Program 24 l

l 1

I i

l APPENDIX C INVENTORY AND INITIAL ASSESSMENT BUSINESS UNIT ACTION PLAN FORM l

l l

l l

CONFIDENTIAL INFORMATION . FOR CP&L USE ONLY 08/04/98

l CP&L Year 2000 Compliance Program Year 2000 inventory & Initial Assessment l Group: Nuclear Generation Group Department:

Section:

Business Unit:

Attached is a complete inventory of all High, Medium, Low and Replaced / Obsolete priority items within rny business unit subject to Year 2000 readiness. The initial assessments include the following for each item

i e Evaluation of failure risk that provides the basis for the priority

} .

Recommended approach / plan for detailed assessment, testing and remediation l . Estimated detailed assessment /remediation cost i

Unless specifically noted otherwise, no further action will be taken to formally assess and remediate Low priority items. Remediation of these items will be done as time and resources

permit within business unit priorities.

4 Items with a Replaced priority were already identified for replacment or are Obsolete. Unless specifically noted otherwise, no further action will be taken to formally assess and remediate

, these items. Their replacement items are listed and assessed separately in the unit inventory.

s l

1 Approval: Business Unit Subject Matter Expert Date 4

Approval: Business Unit Manager Date CP&L 5

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

NGG Year 2000 Readiness Program 25 APPENDIX D 4

' DETAILED ASSESSMENT /REMEDIATION FLOW CHART 3

j 5

4 I .

i

. 1 I

4

' CONFIDENTIAL INFORMATION FOR CP&L USE ONLY 08/04/98

,,_.. - - _ . - . , . . + . - . .- - s--. . - . - ~ . - _

l NGG YEAR 2000 COMPLIANCE PROGRAM l 1

1 Start Detailed Assessment 5 '/. 10%

Test Needed?  :  :

Issue Vendor Vendor input Letter Accepted Yes E

20%

Develop Test I Plan h ir 3 5 '/. 50% Detail Certification Perform Detail 100 % I Perform Test ----* Assessment --* Package

-a Assessment Complete Complete '

a a 1V Remedation No Required Yes

+

Develop Remedation Plan E

60%

lssue Contract ir 80%

install

)

Remedation l l

ir 90% l Post Remedation l Testing

NGG Year 2000 Readiness Program 26 APPENDIX E CERTIFICATION PACKAGE CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98

f l

l I I CP&L Year 2000 Compliance Project Year 2000 Certification Package: i Item Name: File Number:

Business Unit:

Dept. Section Unit Year 2000 Certification Classification:

Certified Year 2000 Compliant.

Certified Year 2000 Ready Approval: Subject Matter Expert Date Approval: IT Unit Manager (if applicable) Date Approval: Business Unit Manager Date Approval: Group / Dept. Year 2000 Project Manager Date C:\Y2K Project Documentation \ 933 - Cert. Doc. doc Revised: 05/25/1998 Confidential . For CP&L Use Only PageI Printed: 06/26/98 i

i CP&L Year 2000 Compliance Project

. DESCRIPTION Provide a brief description of the component / system / application and how it is used.

COMPONENT LIST (optional - for systems with multiple components)

Example: Digital Widget System DEC 490 CPU DEC 1234 Workstation MS DOS 7.0 Operating system Application Version

2.1 REFERENCES

List the sources ofinformation used to make the detailed assessment, e.g. vendor manuals, source code, design drawings, vendor teleconferences and/or correspondence, and test plans.

DETAILED ASSESSMENT RESULTS Interface Evaluation - Describe the interfaces, both internal and external, for passing date and l time related data.

l 1

Vendor Evaluation Discuss available manufacturer / developer infonnation, such as contracts, correspondence, teleconference notes, Internet listings, vendor manuals, vendor user groups, etc. ,

l Test Plans /Results - Provide a test procedure reference (POM number, WR/JO, etc.) or provide I a detailed write-up of the test performed. Testing criteria for dates should follow the CP&L Corporate Testing Guideline. If no test is performed, provide a justification of why it was not required.

Spare Parts Evaluation - Discuss the status of the spare parts in inventory and whether they are identical to the item.

l Training Systems Evaluation - Some systems have duplicates in the plant simulators or traming facilities. If a plant component or system is changed, the training component or system must be changed to match. In addition to the physical changes to equipment or software, training materials may require updates. Provide a description of the training considerations.

Subject Matter Expert Review - Discuss, as appropriate, any other relevant information obtained through walk down, review of embedded microchips, review of source code, etc.

C:\Y2K Project Documentation \ 933 - Cert. Doc. doc Revised: 05/25/1998 Confidential For CP&L Use Only Page 2 Printed: 06/26/98

I CPTL Year 2000 Compliance Project Results - Describe the overall results of the detailed assessment. Provide the remediation recommendations and justification. For example; Digital Widget Recorder, Model XXX is Year 2000 compliant or Digital Widget Recorder, Model XXX is Year 2000 ready with the following recommended remediation activities: Procedure 1234 to be revised to reset the date to "00" upon  !

replacing the backup battery. )

REMEDIATION RESULTS - Only include if remediation actions were required.

]

Describe the completed actions taken for remediation and the results of any post remediation testing done to confirm Year 2000 Compliant or Year 2000 Ready status. For example, ESR 98- 1 00100, Revision 0 implemented and turned over to replace Digital Widget Recorder with Y2K compliant model, or Version 5.0 of Application YY installed, tested and updated in the Software Quality Assurance Manual. ,

1 Provide any contingency plans as deemed appropriate. l l

ATTACHMENTS As required l l

Initial Assessment Sheet l Vendor correspondence l Contracts or contract amendments when applicable (with Y2K warranty)

Test plans C:\Y2K Project Documentation \ 933 Cert. Doc. doc Revised: 05/25/1998 Confidential For CP&L Use Only Page 3 Pnnted: 06/26/98

NGG Year 2000 Readtness Program 27 l

I l

APPENDIX F TECHNICAL CRITERIA CONFIDENTIAL INFORMATION FOR CP&L USE ONLY gg

CP&L Year 2000 Compliance Project i

Year 2000 Compliance Technical Criteria 1

l i

l l

l j

i I

h I

j CMa. Project DocumentatiorA90.,- Criteria - Technical Compliance Revised:12/11/1997  !

Confidential - For CPEL Use Only Pagei Printed: 6/26/1998

CP&L Year 2000 Compliance Project YEAR 2000 COMPLIANCE l Technical Criteria Table of Contents I Introduction II Technical Elements III Year 2000 Compliance Criteria

. 1 IV Interpretation of the Criteria l

I i

l l

Notice: He basis for this document came from material obtained through participation with the CDSV Year 2000 Focus Team. l C:\Y2K Project Dxumentation\905 Criteria Technical Compliance Revised:12/II/1997 Confidential - For CP&L Use Only Page 2 Printed: 6/26/1998

4 CP&L Year 2000 Complianca Project TECHNICAL CRITERIA FOR YEAR 2000 COMPLIANGE L INTRODUCTION BACKGROUND The Year 2000 situation arises fro.m the programming practice of only using two digits for the year instead of four digits (i.e. "85" instead of "1985") in order to save computing resources. When computational resources, both hardware and software, begin mixing dates from the 19xx and 20xx centuries, various and uncertain results can be produced. The results of non-compliant date computations will vary from immediate and apparent failure to situations where processing seems to be proceeding successfully but erroneous data is being stored and communicated waiting to be discovered at some later date.

PURPOSE The purpose of this document is to provide a st:uida-d enterprise-level definition of " Year 2000 compliance" and how compliance will be implemented. It is intended to be used by all Carolina Power & Light entities as a framework for achieving enterprise-wide compliance.

The enterprise level definition of compliance will identify the technical elements of the Year 2000 challenge for criteria for Year 2000 compliance, and a standard interpretation of the criteria.

Official notification and communication of the compliance definition and standards will be made with the publication of this document to the entire enterprise. This document will '

undergo revisions as Carolina Power & Light moves forward with their Year 2000 efforts.

Any changes or revisions to this document will be reviewed and approved by the CP&L Year 2000 Compliance Project management team, and formally communicated to the organization.

DEFINITIONS For the purposes of this document, the following definitions apply:

1. Computational Resources All applications of programming, primarily software but also including firmware or embedded programming in hardware. All criteria apply to computational resources in combination.

a. Software CAY 2K Project Documentation $5 Criteria - Technical Compliance Revised:12/11/1997 Confidential - For CP&L Use Only Page 3 Printed: 6/26/1998

CP&L Year 2000 Compliance Project includes operating systems, end-user application progranuning, third party vendor software, networking software, real-time and batch programming software, telecommunications programming, process control and monitoring software, etc.

b. Firmware and Microcode Includes PLCs, EPROMs or any other programmable hardware changeable by persons other than the OEM.

c. Ihrdware Primarily BIOS chipsets, but also includes embedded programming in automobiles, elevators, clocks, HVAC systems, telecommunications, etc. Also applies to the entire combination of electronic equipment used for calculational processes.

d. Embedded Devices and Systems Includes devices such as sensors, actuators, transducers etc. that are ordinarily considered hardware, yet contain software in the form of firmware, microcode, Application Specific Integrated Circuits, system software etc. Also includes '

complete, integrated systems of such devices. In this category, the entire device or the entire system should conform to the compliance criteria laid out in this document.

2. DBMS Data Base Management System, such as DB2, Oracle, Sybase, ADAB AS, etc.

3. Julian (Ordinal)

Refers to a method of displaying date in which the 2-digit year and the sequential day within that year are shown as "YY.DDD". For example, September 20,1996 is the 264th day of that year, so the Julian representation of that date would be "96.264".

C:\Y2K Project Documentation \905. Criteria . Technical Compliance Revised:12/II/1997 confidential - For CP&L Use Only Page 4 Printed: 6/26/1993

M CP&L Year 2000 Compliance Project

II. TECHNICAL ELEMENTS i

The technical elements of the Year 2000 remediation involve the computational processes of j accepting, creating, manipulating, and outputting calendar-related information. The immediately ,

obvious question that the Year 2000 issue raises is whether computational resources can properly process the change of century to the year 2000. This is of course a high-risk concern, and should i

be of primary importance to remediation efforts. However, several other date-related problems exist in association with the Year 2000 date rollover. These are summarized in Table 1.

Table 1. Technical Elements of the Year 2000 Challenge l

ELEMENT DESCRIPTION EXAMPLE EVENT PP.OB ABLE TIMING

- Century This is the most ecmmon element. Examples of centmy ambiguity Examples of events can Ambiguity Computer represents dates with a can appear in the following events: occur with timing as early I- or 2-digit year. When computer as:

~

does not recognize that dates are not all in the 19xx range, the results are unpredictable.

a. Data edits reject years in a. Bank ATM rejects an otherwise a. First use of cards issued early 20xx as invalid valid bank or credit card with an in 1995.

expiration date of "00".

b. User interface does not b. Lotus 1-2-3 accepts only b. First need to enter allow 4-digit year to 2-digit years which it values later than 1999.

clarify century, assumes to be in 19xx Has already occurred.

only.

c. Sorting leaves dates in 20xx and c. Itemized monthly bili lists c. First monthly data 19xx in jumbled order. transaction for Jan I,2000 processing in 2000.

through Jan 15,2000 followed 1 by Dec.19,1999 through Dec.

31,1999.

d. Durations such as invoice aging d. Invoice age calculated as a d. January,2000 are calculated incorre,:tly. ridiculously large number or as negative number, erroneously 1 triggering overdue notices and staggering interest penalties, e.'Ihe century is truncated or c. Software stores dates in the e. Could happen at any changed between entering and 20xx range using DBMS but time depending on the retrieving a date. only passes 2-digit years to the time horizon of the prcduct. DBMS defaults to system.

19xx and stores.

C:\Y2K Project Documentation \905- Criteria Technical Compliance Revited:12/II/1997 Confidential - For CP&L Ure Only Page 5 Printed: 6/26/1998

1 CPtL Year 2000 Compliance Project

' \'

Table 1. Technical Elements of the Year 2000 Challenge (continued) l

ELEMENT DESCRFf10N EXAMPLE EVENT PROB ABLE TIMING

f. Comparing a date in 19xx with a f. Payroll-deduction calculations f. First quarter of 2000.

date in 20xx assumes both are in for years in 20xx incorrectly '

19xx. mistake the year as 19xx and l fail to apply recent changes in tax

!aws.

Extended in general, specific values for a Some s ,ftware may erroneously Will occur on various Semantics date field are reserved for special process a transaction with a valid days after Dec. 31,1998.

interpretation. The most ecmmon end date in 1999-such as not

]

, example is interpreting "99"in a terminating an expired software ,

2-digit year field as an indefinite license or failing to age back-up l end date, i.e., "does not expire." tapes for rccycling as scratch )

Another is embedding a date value tapes.

in a non-date data element.

Calendar ' Errors typically include failing to Logic sensitive to day-of-week Day of week error will

- Errors treat 2000 as a leap year and will be two days off at the occur Jan 1,2000. Leap converting incorrectly between beginning of the year, and an year error will occur the date representations. Day-of-week additional day off after February first time input data may also be incorrect, since the 28,2000. Calculating day of week contains Feb. 29,2000.

year 2000 begins on a Saturday, for all dates following this will be while 1900 begins on a Monday. incorrect.

Date Many computer products Value for date can revert to a date Happened in the 1980s on Overflow represent dates internally as a base near the base date/ time, to a certain Tandem hosts.

l date/ time plus an offset in days, negative value, or crash the Could happen again at seconds, or microseconds since computer because of an illegal any time to any product that base date/ time. Integers operation. depending on how holding the offset value can product stores dates.

overflow past the maximum corresponding date - an event which may lead to undefined behaviors.

Inconsistent At interface between systems, Software on one side assumes all Could happen at any time Semantics each side assumes semantics of dates in 19xx. Software on other depending on the time data passed; systems must make side assumes years 5199 are horizon of the system.

same century assumptions about 19xx, and 00 50 are 20xx.

2-digit years.

i 4

CAY 2K Project Documentation \905. Criteria - Technical Compliance Revised:12/11/1997 Confidential - For CPKL Use Only Page 6 Printed: 6/26/1998

CP&L Year 2000 Compliance Project III. YEAR 2000 COMPLIANCE CRITERIA This document requires that computational resources satisfy the General integrity and Date integrity criteria, and either the Explicit or Implicit century criteria. It is preferred and recommended that both the Explicit and Implicit criteria be met if possible, although meeting one or the other of these criteria is acceptable. Resources (hardware, software, or "firmware") that

- meet these conditions will be considered " Year 2000 Compliant" These criteria are listed in Table 2.

Table 2. Four Criteria for " Year 2000 Compliance" CRITERlON DESCRIFTION Generalintegrity No value for current date will cause interruptions in desired operation.

Date integrity All manipulations of calendar-related data (dates, durations, days of week,

. etc.) will produce desired results for all valid date values within the operational domain.

Explicit century Date elements in interfaces and data storage permit specifying century to eliminate ambiguity.

Implicit century For any date element represented without century, the correct century is unambiguous for all manipulations involving that element.

Each criterion as described in this table is intended to be a general requirement. The following sections describe the criteria in more detail.

A. General Integrity As a system date advances normally on a computer resource, each date roll-over must not lead the computer resource (including, but not limited to, the host processor and any

. software executing there) to erroneous processing. This must also be tme if the system date is regressed to a prior date. All date roll-overs must be transparent to the user.

The best-recognized, high-risk date change is roll-over to 2000, although all other roll-overs such as Feb. 29 also apply. The term " desired operation" in Table 2 is intentionally broad and must be interpreted for specific technologies and applications.

B. Date Integrity This criterion primarily covers the correctness of manipulations of date data as described in Table 3. These manipulations need to be reliable only over the range of dates that a computer resource is expected to handle.

For example, sales-order processing may handle dates from 5 years in the past to one year in the future. In contrast, an employee database may store dates of birth from early in the 20th century to planned retirement dates well into the 21st century.

4 C:\Y2K Project Documentation \905- Criteria - Technical Compliance Revised:12/11/1997 Confidential - For CF&L Use Only Page 7 Printed: 6/26/1998

, CP&L Year 2000 Compliance Project 1

Table 3. Variety of Manipulation of Date Data Category Examples of Manipulation i

Arithmetic . Calculate the duration between two dates

• Calculate date based on starting date and duration e

' Calculate day of week, day within year, and week within year e Hashing calculation using year as divisor Branching

• Compare two dates Format e Convert between date representation (YMD, Julian, etc.)

e Reference same data address with different variables Data Storage e Storing and retrieving e Sorting and merging

• Searching

. Indexing on disk file or database table

]

e Moving data within primary memory Extended Semantics e "99" as special value for year e "99.365" as special value for Julian year

• "00" as special value for year C. Explicit Century This criterion essentially requires the capability to store explicit values for century. For example, third-party products that can use a 4-digit year in all date data elements stored and passed across each interface (including the user interface) would satisfy this criterion. A base-and-offset representation of dates that covers all centuries of interest would also satisfy this criterion. Whether this capability should be used to eliminate century ambiguity is part i of the last criterion.

D. Implicit Century This last criterion requires that, if the century is not explicitly provided, its value can be correctly inferred with 100% accuracy from the value of date provided. For example, the range of values for an " invoice date" would very rarely span more than 10 years. Because the century can always be guessed correctly from an invoice date with a 2-digit year, this date data element would satisfy this criterion.

Note that this criterion permits cost-risk trade-offs that minimize changes to existing date formats.

IV. INTERPRETATION OF THE CRITERIA A. STANDARD INTERPRETATION C:\Y2K Project Documentation \905 Criteria - Technical Compliance ReviseE15i1/1997 Confidential - For CP&L Use Only Page8 Printed: 6/26/1998 l

CPEL Year 2000 Compliance Project d

Although these four criteria fully define Year 2000 Compliance, compliance represents a balance between cost and risk rather than an absolute yardstick. Such a balance will vary with each organization, according to its business needs and technological base.

j Consequently, organizations will possibly require a greater level of detail to absolutely interpret how these criteria apply to that organization.

Table 4 contains the standard interpretation of these criteria. Any deviation from this interpretation in a Carolina Power & Light organization must be documented and approved by both the organization and by the provider of the computational resource.

. Note the importance of clearly identifying the specific date ranges for compliance, j reasonable latitude in date format, and situations under which implicit century values will be

~

tolerated. Also note that certain exceptions are included to support important options for cost / risk trade-off.

d 4

i i

i 1

l C:\Y2K Project Documentation \905- Criteria Technical Compliance Revised:12/ll/1997 l confidential - For CP&L Use Only Page 9 Printed: 6/26/1998

CP&L Year 2000 Compliance Project t

Table 4. Interpretation of Year 2000 Compliance Criteria Criterion Description of Criterion Interpretation of Criterion GeneralIntegrity No value for current date will e All computational resources will function correctly, without human intervention, and transparent to cause interruptions in desired the user, for til values of system date between 1900-01-01 and 2050-12-31 operation. o Of special interest are the following dates and the ability to roll over forwards and backwards to the correct sext date: 1998-12-31,1999-09-09,1999-12-31,2000-01-01,2000-02-28,2000-02-29,2000-03-0I,2000-12-31,2001-01-01,2027-12-31.

Date Integrity All manipulations of calendar-

• Computing resources must correctly handle all representation and manipulation of dates with values related data (dates, durations, between 1900-01-01 and 2050-12-31. Especially important is that all years divisible by 4 in this 150-days of week, etc.) will year range are leap years except 1900.

produce desired results for all e All computational resources developed for Carolina Power & Light must initialize all date elements valid date values within the with either all zeros (0000-00-00) or null values. Null values are defined for each application by the operational domain.

development facilities, such as the language compiler. A null-value feature is strongly recommended in third-party product selection.

All developed software must not contain literals or constants for dates unless required to capture specific business rules such as calculations of payroll deductions.

All developed software must not use special date values as logical flags, such as "99" as year to mean "no end date" or "00" to mean Ws not apply". '

Exceptions:

i e

Valid date ranges in existing developed or existing third-party software may start with the oldest date value in the application's archived data rather thari 1900-01-01 when there is no business need to '

support earlierdates.

t i

C:\Y2K Project Documentation \905- Criteria - Technical Compliance Revised:12/11/1997 Confidential - For CP&L Use Only Page 10 Printed: 6/26/1998

CP&L Year 2000 Cosapliance Project Table 4, Interpretation of Year 2000 Compliance Criteria (continued)

Criterion Description of Criterion Interpretation of Criterion Explicit Century Date elements in interfaces e All developed and third-party software must permit the use of date formats which explicitly specify and data storage permit century in all date data stored or transmitted. Re format of these date elements must be YYYYMMDD specifying century to or YYYYJJJ as specified by ANSI X3.30-1985(R1991) unless superseded by another application-elimimte date ambiguity. specific standard or convention.

In storing or transmitting date data, some applications must conform to domain-specific standards, contractual agreements, or APIS to necessary third-party products whose date formats must supersede ANSI X3.30 as appropriate within the application. Examples of these standards are listed in Table 5.

e Hird-party products must permit formatting data with explicit century in the user interface.

All developed applications usfng third-party products must always explicitly supply century and never rely on those products' default value for century.

Exceptions:

e For date data formatted for a user interface, it is acceptable to use punctuation (slash, hyphen, period, comma) within a formatted date, to spell out or abbreviate the name of the month, or to reorder year-month-day to serve customs among the end users.

DBMSs whi<:h cannot store date in conformance with SQL standards but do store century explicitly (such as DD-MMM-YYYY) are acceptable.

• Default values for century are permitted only when supplied by data-entry aids and the end-user can verify the defaulted value before committing the data.

Implicit Century For any date element e Century must be explicit in all date data stored or transmitted unless the correct century can be inferred represented without century, with 100% accuracy based on the value for date. Explicit century is preferred where practical.

the correct century is e Developed and third-party software may imply century in the user interface in the format YYMMDD or  !

unambiguous for all YYJJJ (as specified by ANSI X3.30). I manipulations involving that e in storing or transmitting date data, some applications must conform to domain-specific standa-ds  !

element.

whose requirements for dates may supersede ANSI X3.30 as appropriate within the application.

Examples of these standards are listed in Table 5. t Exceptions:  ;

e For date data formatted for a user interface, it is acceptable to use punctuation such as slash within a formatted date, to spell out or abbreviate the name of the month, or to reorder year-month-day to serve ,

customs among the end users.

CAY 2K Project Documentation \905- Criteria - Technical Compliance Revised:12/11/1997 Confidential - For CP&L Use Only Page 11 Printed: 6/26/1998

~

CP&L Year 2000 Compliance Project i

Table 5. Additional Year 2000 Compliance Criteria Interpretations Criterion Description of Criterion Interpretation of Criterion f

_xap Year For any year that is either . Day-in-year calculations must address 366 days not 365.

evenly divisible by 400 or Calculation e Day-of-the-week calculations must address the fact that 28 February 2000 is a Monday and i March I is evenly divisible by 4 and not a Wednesday, not a Tuesday which is February 29,2000.

evenly by 100, there are .. Week-of-the-year calculations. He i 1* week of the year 2000 is 5 through i I March, not 6 through 12 potential exposures. March.

Special Values Fixed dates cannot be used

• Certain years cannot be used as an "end of input" flag, e.g. 99 and 00.

as a globalindicator. . Certain dates cannot be used to indicate "no-expiration", e.g. 12/31/99. ,

Century All manipulations of century e Rollover to 1/1/2000 - The calculation of 12/31/1999 23 59:59 plus I second must produce 1/1/2000 Calculations data will produce desired 00:00:00.

results for all valid date . Pre-2000 Calculations - The calculation of 12/31/1999 plus I day must produce I/1/2000.

values within the operational . Post-2000 Calculations -De calculation of 1/1/2000 less I day must product 12/31/1999.

domain.

t l

v i

i i

C:\Y2K Project Documentation \905- Criteria - Technical Compliance Revised:12/1I/1997 ,

Confidential - For CPEL Use Only Page 12 Printed: 6/26/1998 i

i . 'CPtL Year 2000 Compliance Project ,

i l p  ;

)

4 B. STANDARD, DATE FORMAT 1-L 't. Date Storage:

l l e All dates stored in files or data bases should be changed to conform to CP&L

! Data Planning Standards for date format. The format is CCYYMMDD where {

t CC = Century, YY = Year, MM = Month, DD = Day, i e If the application already stores the century as part of the date but in a non standard format (i.e. MMDDCCYY), no rework should occur.

. The Picture and Usage of a date is often language dependent, whenever possible dates should be defined as numeric, For example, when programming 4

with COBOL the standard is PIC 9(8) COMP-3.

, e Some SQL based applications might need to use the DB2 Date data type. The

~

latter usage should be evaluated for complexity resulting from valid date i requirements along with methods used for editing and error processing. For l- example, if the application performs an edit for a valid date prior to the DB2 check then this storage method might be more complex than if the date was stored as numeric,

]

a

. Dates that are optional, not known or not applicable should be stored as zeros.

Dates stored as 12/31/99,99/99/99,9/9/99,993(5 or some other "special value" )

i should be changed to store zeros. The use of special value dates to provide

some non-date information should be eliminated. If the DB2 date data type is used then the highest possible date, 12/31/9999, should be used.

{

j e Other dates: (MM/YY, YY or Julian) These formats should follow the

numeric storage standard to include the century respectively. Zeros for optional i dates should also be used.

l

2. Date Displays:

• Dates displayed on reports should follow the CP&L ITSD standard format of e MM/DD/YY. Non-entered (missing, or null entry) dates should be displayed as l blank.

e Dates displayed on screens should follow the CP&L ITSD standard format of

MM/DD/YY. Non-entered (missing or null entry) dates should be displayed as

blank.

e If the DB2 date data type is used, then an interpretation routine to convert the j- date to a blank prior to its display will be necessary.

• Dates that already display the century on reports or screens should not be i;

changed.

i

C

\Y2K Project Documentation \905. Criteria - Technical Compliance Revised:12/1I/1997 l confidential - For CPsL Use Only Page 13 Printed: 6/26/1998 1

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

i I

! CP&L Year 2000 Compliance Project

^

• Other displays can include MM/YY, YY or Julian YY/DDD formats. Blank displays as mentioned previously should be used for these dates as well when the dates are non-entered.

3. Common Routines:

e Standard CP&L date routines exist for the mainframe computing environment l

i (SWBDTO, SWBDTB#1, SWBDTB#2) and should be used whenever possible.

The include members are in Endevor as follows:

O CICS: MWBDTOC1, WWDBTOCl, WWDBATCl 0 B ATCH: MWBDTBCl, WWBDTBC 1, WWDB ATC1 0 DYL280: WWDBTBC2

• A standard COBOL routine for interpreting a 2 character year and appending the century is also available. The standard includes a year interpretation of less than 70 to append 20 for the century otherwise 19 is appended for the century.

Applications should use this routine for appending the century whenever possible (see RMMDTWS and RMMPRDT in Endevor). This standard may not be applicable in all cases. For example; A Human Resource application that tracks binh dates and employment dates prior to 1970. The application should require the century for both the data entry and for the display of these types of dates. These dates will be considered exceptions.

• Languages that cannot utilize these common routines for date processing should have similar routines available. Creation of these routines for each language should be planned for prior to the remediation of the relevant applications.

4. General:

• Standardizing the format for date data is an important part of Year 2000 compliance. Although several standards for date data format are available, the criteria in this document take precedence over other date standards. These other date standards may be used, as long as the criteria in this document are met.

Additionally, two considerations need to be made when evaluating computing resources for compliance.

O Limitations in Standards .

None of the 3 standards for date representation (ANSI, ISO, FIPS) i mandates a 4-digit year for ALL calendar data. For example, conformance l to ANSI X3.30 does not eliminate century ambiguity from all date  ;

variables and interfaces. Instead, conformance simply reduces the variety of formats occurring in the computing resource.

O Accommodating Conflicts

~

C:\Y2K Project Docu' mentation \905 Criteria - Technical Compliance Revised:12/11/1997 ,

confidential - For CP&L Use Only Page 14 Printed: 6/26/1998 l l

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

CPEL Year 2000 Compliance Project 4

While trying to conform to ANSI X3.30, some applications may need to satisfy other standards or conventions for date representation. Table 6 lists examples of standards with date representations that may supersede ANSI X3.30 in specific applications. In addition, the criteria and performance expectations set forth in this document take precedence over all other standards or conventions.

i Table 6. Examples of Standards which may Supersede ANSI X3.30 Domain Standard i Interoperability with international ISO 8601 (1988) concerns S'QL ANSI X3.135-1992, ISO-lEC 9075:1992, or FIPS 127-2 Exchange of call-billing data Bellcore SR-STS-00320 (EMI)

(Call _ Data Records Switch manufacturers proprietary formats Credit cards, debit cards, ATM ISO-IEC 7813, ISO 4909 cards Electronic commerce (EDI) ASC X12 EDI draft std for trial use, ISO 9735, UN/EDIFACT I

C:\Y2K Project Documentation \5KE- Criteria - Technical Compliance Revised:12/II/1997 Confidential - For CP&L Use Only Page 15 Printed: 6/26/1998

NGG Year 2000 Readiness Program 28 1

i I

J APPENDIX G TESTING GUIDELINES i

I l

l CONFIDENTIAL INFORMATION - FOR CP&L USE ONLY 08/04/98

CP&L Year 2000 Compliance Project 4

Year 2000 Compliance Testing Guidelines l

1

~

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Pagei Printed: 06/26/98

l CP&L Year 2000 Compliance Project YEAR 2000 COMPLIANCE Technical Criteria 1

Table of Contents

1) I n t rod u c (10 n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

2) General Discussion of Testing & Evaluation............................ .................. 4

3) Embedded Systems - Some Considerations.. ....... . .. ................... ..... ......... .... 6 )

4) Affect of Resolution Strategies on the Testing Approach................................ 7

5) Sys tem Evalua tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6) Da te/ri me No ta tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .l

7) C r1 t ical D a tes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .!

8) Checkin g for Compliance.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .. . . . . . . .. . . . . . . . . . . . . . . . . . . .. 12 Appendices:  ;

i

1. Co'.nmon Date-Dependent Non.Date Functions

2. Year 2000 Compliance Checklist

3. Year 2000 Compliance Test Plan l

1 1

I Notice: Much of the information contained in this document was obtained from the MITRE Corporation Year l 2000 Website (http1/www.mitm.org/resewch/y2k/) 'Ihe MITRE Corporation asks that the following statement be included in documents that use their documents as sources.

Unless otherwise indicated, all information on this system is considered public information and may be dit tributed or i copied, provided that it includes attribution and this paragraph, and that no fee is charged other than the ac ual cost l of transmission er reproduction or the standard connection-time charges on a BBS. on-line service, or Internet l connection. It may not be distributed for financial gain or included in a commercial collection or compilation without l prior permission from the copyright owner. l

~

C:\Y2K Project Documentation \905- Testing Guidelines Revi;ed: 01/16/1998 Page 2 Printed: 06/26/98 m

CPEL Year'2000 Compliance Project Introduction ,

l Traditionally, conventional wisdom holds that the purpose of testing is to find errors. For the  !

most part, this is true, but as in many things the "doing" is not quite that clearly defined. This document presents an introductory look at the process of testing products (application software, firmware, computing hardware or devices), for Year 2000 (Y2K) compliance. Major topics covered in this document include:

. Testing and evaluation, and how they apply durit; ' ., a assessment and validation activities e Considerations for embedded systems i e Resolution strategies and their effect on the testing process e Discussion on the evaluation of systems or products e Date and time notation

• Criti. cal date transitions (Midnight, December 31,1999 isn't the only one)

• Checking for Compliance (how to)

CAUTION!

Testers and evaluators must be caref t! u i executing test scenarios that involve advanced dates. Simolv setting the system cloa n trd may cause unanticipated effects. For example, setting the date forward to December 3 a, is99, which is currently two-plus years in the future -

could cause software licenses to expire, or passwords, or user accounts, or files, etc., to fail.

The mie for Y2K evaluation and testing should be: Test on an isolated system that has been thoroughly backed us.

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 3 Printed: 06/26/98

t '

1 a

CPtsL Year 2000 Compliance Project General Discussion of Testine & Evaluation

, l

)

l:

Testing is the gathering of information of product by operating or using it for the purpose of discovering, verifying and/or validating the actual performance. If we are product developers, we l execute tests to find what kinds of errors still exist - this is conventional testing. However, as 1 Y2K evaluators we should execute tests to do the following: j i l i e Locate Y2K issues - places where we nay have to make changes  ;

. Ensure that the changed product operates as well as it did prior to making changes -

l

) regression testing j

e Determine how well the changed product will operate at the Y2K transition and

.. afterward - validation testing  !

As testing proceeds, the information gathered is used to evaluate the risk that the product will not i support the user's needs before, during or after the Y2K transition. The testing information, our knowledge of work processes and the user's inputs are used to determine if these risks are acceptable. Finally, if the risks are not acceptable, we use the testing information gathered to develop resolution strategies. The first two of these, establishing and analyzing risks,is called evaluation. The third, resolution may lead to changing the product, changes in operation procedures, product retirement and/or replacement. When the product changes are complete or the product is replaced, we evaluate again.

Locating Date Issues

- For many applications and devices, particularly newer ones, date issues can be identified from available documentation and source code. Requirements specifications and design documents (if they are current and contain adequate detail) are particularly useful sources ofinformation. .

Additionally, user documentation (maintenance guides and user manuals) can also identify date- 1 related functions. The source code, of course, is the ultimate identifier of date functions within an application.

It shouldn't be overlooked that most of this documentation, including the code, doesn't say much about how the surrounding " infrastructure" uses dates. By infrastructure, we mean:

• The supporting operating system, firmware and system software  ;

e Database management systems '

e Communications packages To establish the iate issues of these infrastructure components, each must be evaluated 3 individually, or the complete system, application plus infrastructure, must be subjected to a senes j of tests that explor: operational behavior around those dates that are critical to the system's operation.

- C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998  ;

Page 4 Printed: 06/26/98

4 CPtL Yont 2000 Compliance Project Ensure Renovations Haven't Broken Anything Once Y2K mod;fi;ttions have been made, the tester / evaluator must determine if anything was broken by the modifications. This is called regression testing. In the strictest sense of the term, the only true regression test is a complete retest of the product against all relevant specifications (including user expectations and current modes of operation). Often, though, it is possible to develop some subset of such an exhaustive test that can be used as a health check to determine if any critical functionality has been lost.

Verify Y2K Operation

Validation of correct Y2K operation (in all its forms) involves operating the product in a " time-advanced" environment. A number of tests are required, at least one at each of the identified critical dates and one for each relevant date horizon at each critical date.

C:\Y2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page5 Printed: 06/26/98

CPEsL Year 2000 Compliance Project Embedded Systems - Considerations Embedded systems pose many unique challenges for testing and remediation of Year 2000 issues. These can be broadly categorized as follows:

cArchitectural:

• There is a wide prevalence of four bit and eight bit processors such as those manufactured by Intel, Zilog and Advanced Micro Devices. Many of these have a limited instruction set. Many of these micro-controllers have a two-digit date representation for arithmetic and logical operations.

• Date representation may be different for ' power on ' conditions and la battery backup conditions.

e There is no standard way to encode dates between products made by different vendors.

Programming:

• Source code is not available for many of these systems.

• Object code may be stored in different levels of firmware, such as programmable logic arrays (PLA's), Flash ROM, CMOS or BIOS.

e Object code may be hard coded, re-loadable or re-entrant.

• Program may be recording real time intervals based on calendar dates rather than actual dates themselves.

Configuration:

• Systems may consist of upstream and downstream devices that have data interfaces between them.

• Downstream devices may have dates that are set or overridden by upstream devices.

• Systems may have extemal interfaces that transmit and receive date information.

Operational:

• The system may be in a production environment that it cannot be taken out of without severe impact.

• Backup systems may not be available, in case of failure during testing.

• Many systems may not revert back to current dates after dates are advanced during testing.

• Warranties, inspection and service logs may be voided by date advancement.

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998' Page 6 Printed: 06/26/98

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

CPfL Year 2000 Compliance Project Affect of Resolution Stratenies on the Testine Approach 1 There are a number of ways to attempt to achieve Y2K compliance. The Y2K solutions that an i evaluator is most likely to encounter are

i

. System replacement

. Expansion in files to dates with four-digit-years

e Compression in files to dates with four-digit years e Windowing e Encapsulation l!

System Replacement We can dispense with replacement quickly because the new system must be evaluated just like any other new system, except that Y2K survivability is a requirement.

Field Expansion )

Field expansion is the "right way" to achieve Y2K compliance because it converts the product to dates with full four-digit years, but it is also the most far-reaching because it is applied to the data files with which the product works. This requires changes to data, data structures, and to code.  ;

Components of the product that reference the altered files, even if they perform no date manipulations, must be recompiled to accommodate the new date stmetures. It is by far the most comprehensive, but it also requires the most testing -- virtually everything is put at risk.

Field Compression Field compression also involves changes to data; specifically it requires encoding or " packing" i the four-digit year into the two digits currently allocated. Data and code must be changed. j Whether or not data structures must change depends upon the compression algorithm and the l language involved. This approach also results in less straight-forward and more complex coding that will most likely add to the maintenance overhead of the product. Each date reference is a possible candidate for change and, hence, for testing.

Field Windowing Field windowing doesn't require changes to data, but does require significant changes to the code.

In comphx products, with many date manipulations that cannot be isolated in a few places, the i risk ofire 'vertently changing something not intended can be quite high. If this is the case, field windowing may require a great deal of regression testing. If, on the other hand, the date manipulations are localized, field windowing may require the least regression testing of any

- technique.

Program Encapsulation Program encapsulation requires little or no change to tae existing product and none to data files, but does require the development of the encapsulation code which must be tested exactly as any other newly developed software.

System Evaluation C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 7 Printed: 06/26/98

a J

CPsL Year 2000 Compliance Project The following two questions need to be answered before a product can be evaluated:

1.What are you evaluating?

2 What does it do?

l l

What Are You Evaluating?

This may seem a simple question, but it's very much the key to keeping the evaluation process under control.

The typical system is composed of many components. If you have a system with a well defined architecture you may be able to identify all the components. If you can identify all the components, then you can make some logical choices about how much of the system you are going to evaluate, and, more importantly, you can determine those components whose l compliance status you will leave to others.

J If your system isn't cleanly designed, or, worse, if you don't know how it is designed, then you'll have to do some analysis to determine exactly what parts of it you are going to evaluate. In any case, you'll want to include a complete system test (treating the system as a black box) as part of l the evaluation. This is particularly important in the case where the design cannot be cleanly ,

I determined.

What Does It Do?

If a product has no date-related functionality that is used, it may be Y2K compliant even though j

~

some or all of its components are non-compliant. Investigation is still required because there may be hidden date dependencies. Also, these products should be monitored carefully for cases where the use of the product changes to include date-related functionality. In these cases, the product must be evaluated for Y2K compliance prior to being put into use.

In determining what a product does, it is not sufficient to examine only requirements specifications. One must also look to user expectations (what does the user think the product does or will do?) and to the users' methods of operation (how does she/he use the product?).

' If the system being evaluated utilizes a operating system or other component that maintains the date and time, the Y2K transition might cause one or all of them to fail, even though the system's function is totally date independent.

C:\Y2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page 8 Printed: 06/26/98

l 4

CPEL Year 2000 Compliance Project Daterrime Definitions and Critical Dates for Year 2000 International calendar The international calendar currently followed in almost all countries is the Julian calendar with the Gregorian correction, or simply called the Gregorian calendar.

This is a solar calendar since it is based on the time it takes the earth to revolve round the sun. It consists of 12 months in a year. Each month consists of a specified number of days. Only the second month February consists of 28 days in common years and 29 in leap years. Thus common years have 365 days and leap years have 366 days.

Leap Year A leap year is a year in which an extra day has been added (February 29'h) to adjust for the discrepancy arising out of the normal year period of 365 days and the actual solar year based on the earth's revolution which is 365.242199 (365 days,5 hours5.787037e-5 days <br />0.00139 hours <br />8.267196e-6 weeks <br />1.9025e-6 months <br />,48 minutes and 46 seconds).

As per the Julian Calendar every year divisible by four was a leap year. This led to a discrepancy of 3.12 extra days over four centuries. Pope Gregory corrected this in 1582 by changing the leap year calculation to exclude century years from being leap years unless they are divisible by 400.

There was also a further refinement, which stated that years divisible by 4000 are common years or non- leap years. With these refinements, the discrepancy between the calendar time and the actual solar time is reduced to one day over four thousand years. Therefore, the years 1900 and 2100 are not leap years, while the years 1600 and 2000 are leap years.

Julian representation of a date The Julian representation of a date is the format DDD,YY or DDD,YYYY where DDD is a number from 1 to 365 or 366 depending on whether the year was a common year or a leap year and YY or YYYY is the two digit or four digit representation of the year. i i

1 Gregorian representation of a date l The Gregorian representation of a date is the format DD/MM/YY, MM/DD/YY or any of the other common formats currently used that incorporate date, month and year. In a system , dates

, may be stored in Gregorian or Julian representation, or a combination of both. There are also situations where all internal representation and calculations are done using the Julian l representations and all external interfaces and displays use the Gregorian representation l l

l l

9 C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 9 Printed: 06/26/98

l l

l CP&L Year 2000 Compliance Project Critical Dates Basic Set of Critical Dates The dates discussed here constitute the minimum set of critical dates that must be examined to determine if a system or product is Y2K compliant.

December 31,1999 to January 1,2000: This is the basic Y2K transition (occasionally called the " millennium transition") and the one that is most likely to cause a product to fail ,

catastrophically.  !

February 28,2000 to February 29,2000: The year 2000 is also a leap year, although some systems might not know that. This transition must be examined to determine that the product  !

performs the leap year calculation correctly.

1 February 29,2000 to March 1,2000: At one time, there was a rumor circulating in Y2K ,

circles that the year 2000 is a " double leap year", that is, that is would also have a February 30 "in addition to the 29th. Not true, and in any event, this transition should be checked to I complete the leap year verification. '

l December 30,2000 to January 1,2001: This is the same as December 31 if there is a bad leap year calculation. 1 i

December 31,2000 to January 1,2001: This is the last of the minimum set of Year 2000 transitions and takes the system completely into the new century. It also completes the leap year evaluation by establishing that the product "knows" that the year 2000 has 366 days.

l Other Critical Dates Some systems may have vulnerabilities to other date transitions than those listed above. Financial systems, for example, are very liable to be sensitive to the rollover of fiscal years in addition to calendar years. For financial systems that follow the government fiscal year, the evaluators should consider the following: ,

l September 30,1999 to October 1,1999: This is the last fiscal rollover prior to Y2K.

_ September 30,2000 to October 1,2000: This is the first fiscal a r lover following Y2K.  !

For systems following different fiscal years, the selected dates should be adjusted accordingly.

Magical Dates There are also certain magical dates that may be critical because some fields in the date are used as flags to indicate special situations or circumstances to the software. Any time in the year 1999 could cause problems like this if the software developer used a year value of 99 to mean something special such as, "never purge." The date 9/9/99 might be critical if the software treats a date containing 9s as a special flag. The number of possible " magical" dates is limitless and the evaluators will nW to be creative and thorough in seeking them out and adding them to the list C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 10 Printed: 06/26/98

1 CP&L' Year 2000 Complianc'e Project of test scenarios. It is up to the evaluator, developer, and test staff to determine what that is for each product.

)

Date Horizons -

It may not be sufficient to simply observe the product across each of the identified critical dates.

This is because of"date horizons" that the product may have. Date horizons determine the product's time interval of interest.

The product's " leading date horizon" determines its view into the future, and the " trailing date horizon" determines its view into the past. A forecasting system that predicts staffing requirements for the next six months has a leading date horizon of six months. Similarly, a program that calculates productivity over the past month has a trailing date horizon of one month. Some systems have only a single date horizon, either leading or trailing, and some have both.

For systems with date horizons, it will be necessary to execute test scenarios that cause the '

relevant. horizons to cross the selected critical dates, in addition to causing " time now" to cross each date. If the date horizons are so long that the test setup cannot be tied up to permit the continuous flow of leading date horizon, time now, and trailing date horizon to cross the critical

' date, the scenarios need to be broken into pieces. In such cases, care must be taken to ensure that the test data from the leading date horizon, through time now, through trailing date horizon, is consistent so that a true picture of product eperation can be obtained.

l l

l l

~

C:\Y2K Project Documentation \93S. Testing Guidelines Revised: 01/16/1998 PageiI Printed: 06/26/98

w. __ -.

l CP&L Year 2000 Compliance Project l Checking for Compliance The steps required to make a system or product Y2K compliant are:

1. Awareness;

2. Assessment; i a. Impact Analysis i b. Inspection;

c. System monitoring;

d. Evaluation;

3. Correction;

4. Testing / Validation;

.; 5. (Re-) Deployment.

IM W rhine  %.,.c.nr I tw3..,m.n, b bN l

g e n erSe neeemne, 4 l [ hey jewwnwnes

lasarnesenn an (wron =me w.m..n tenn.herk er neree. ore 1L u

a

---e.w  : vos sv.u w treeswww en rnreweverse at neee y,, n ,4 g ,,,,,

i Ih Cadr*8'"a"* **d D*'*8*** Wees.edne 4emovets Taede '

M %=dena* Taa8* L- - . __ L. J Todene fanse 88***#8' % M T**de Reevuuden Tamano Tania

$ b

\ ' P.

]

y -

c.e.e -

u' , , , , , , , ,

c, e, W eswwasr . - ad ness . --y p" twine ener.cn., Acunse ~~U " I rewe ah ness raareensensen 4 T. - Tante Sun.atene Trorque Tambs \ ; ', rheese ism.e6ee and Vaaweenne Tewde 1 Omaten fless asensgeme Teses l'*Mll Sterm/ Phases where Y2K evaluation is concentrated Figure 1-Checking for Compliance Evaluating for Compliance As shown in Figure 1, the three Y2K compliance steps or phases most conducive to evaluation are Inspection, System Monitoring, and Testing / Evaluation.

C:\Y2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 o, . i , m.., . nuwoe

1. l

'CP&L Year 2000 Compliance Project 1

l During the Inspection step, all available documentation is examined to determine the nature of I the product's date and time processing. This documentation includes:  ;

Specifications which identify date processing requirements;

• Design documents which, if current, identify date-processing algorithms and other algorithms that may use the date; i

• Code for software products which will show the specifics of date pro:essing and which, in the case ofinadequate design documents, may provide the basis of design recovery; User documentation, which may be the most up-to-date documentation available, will identify date processing that directly supports the user or derives from the user.

The System Monitoring step is used to establish date usage and processing when such is not clear from available documentation.

During the Testing / Validation phase, the product is subjected to a series of test cases designed to l validate the correct use and processing of date information by the product.

Inspecting for Compliance When we inspect a system for compliance, we utilize the user requirements, the design specifications, and the actual system code.

The user requirements tell us what the system is supposed to do. If the user requirements involve dates and date processing, changes may be required to attain Y2K compliance, and we have identified an area where we must test explicitly for compliance. However, the user requirements do not specifically identify the component or module that actually does the date processing and often does not discuss date processing in support of"non-date functions." For this information,

. we must turn to the design specifications.

The design specifications will show how the designer of the product intended it to comply with the user requirements. If these specifications are current, we can use them to identify the specific components or modules that do date processing. From these we can go directly to the code that implements the design. Additionally, the design specifications will be a source for test cases that supplement those from the user requirements.

If the design specifications are inadequate or out of date, it may be possible to recover design information from the code. Design information is then used to generate test cases for use in the validation phase.

System Monitoring If date processing is suspected but cannot be verified either because of inadequate design documentation, missing source code, or both, it may be possible to extract date processing information by actually observing the product in operation (either real world, or in a laboratory situation).

CAY 2K Project Documenta$ ion \905- Testing Guidelines Revised: 01/16/1998 Page 13 Printed: 06/26/98

l l

CP&L Year 2000 Compliance Project

------>- System B V

1 1

Figure 2-Determining Date Processing by System Monitoring System monitoring can consist of simple manual observation, or, as shown in Figure 2, it can involve the actual attachment of a monitoring device to the interface or interfaces into and out of the product.

If a monitoring device is used, the natural question is, "Where does it come from?" In many cases, it will have to be specifically developed and the problem of validating the monitor will have to be addreswd.

Using a Compliance Checklist As part of a Y2K validation effort, it is useful to survey the product in an comprehensive way to l determine the full scope of the correction and evaluation effort. The best way to do this is with  ;

i the help of a compliance checklist that has been developed independently of the product '

development activity. Appendix 2 is a checklist derived from the DOD checklist. It provides a DOD-wide means of documenting and reporting on a product's Y2K status in the areas of i

• Year 2000 processing i -

Indirect date usage Leap year Internal date processing Extemal system interfaces Date field types

• Year 2000 testing Off-the-shelf components A checklist like this helps ensure a thorough analysis of the product and also makes its Y2K status available to the users ofinterfacing products in a format that is consistent with the analyses of other products. A checklist is not, however, a specification. Evaluators should not take the attitude that they will evaluate a product in accordance with or against the checklist. The checklist is used to ensure thoroughness and consistency in the evaluation; it does not specifically indicate what constitutes compliance.

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/199E Page 14 Printed: 06/26/98

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

CPfaL Year 2000 Compliance Project i

Evaluating Off The Shelf Products When evaluating off the-shelf products several factors need to be considered

l The vendor usually does not publicize the complete product specification or even a i complete list of functions;

• Source code is almost never available; j -

The vendor does not warrant the product for satisfactory operW , regardless of j claims made in the documentation or promotional literature; and  :

The user / evaluator does not own the product, but is licensed to use the product under i specific conditions (which may not include reverse engineering to recover design or I

{ functionalinformation).

It is also the case that the number of off-the-shelf products that must be evaluated, particularly in a system-of-systems and open architecture environment may be so large that exhaustive j evaluation is not possible with the resources available.

l The challenge faced by the Y2K compliance evaluator is to overcome the lack ofinternal product l information and develop some measure of compliance for all products. l l

Evaluating Without a Specification ,

e Since it is given that there is no available specification for the product, the evaluator is facea With the problem of accumulating product knowledge from other sources. There are a number of

. ways to do this

i.

i.

What user documentation does exist often contains a number of clues about date processing. In particular, the user interface is likely to be well described, and it may

, only be necessary to look up the word "date" in the index to establish the explicit date j- functions performed by the product. Even without an index, a cover-to-cover reading

! (or a search of a scanned document) should reveal the kinds of specific date functions provided by the product.

1 -

User documentation usually does not describe "non-date functions" that are performed i or provided in a date-related fashion (the unique naming of temporary files based on 4

the date and time-of-day, for example). In these cases, users with experience with the product and the product vendor can be helpful.

}

• As a last resort, a generic list of functions performed by various categories of products i (Appendix 1 is an example) can be consulted.

. For each of the date-related functions, one or more test cases can be developed.

!~

1 It is also useful to examine the system function the product is providing in the operational j environment. For example, a graphic user interface may provide date displays; and a database 4 management system may provide data storage and retrieval based on date or date-time information. By listing the date-related functions that are important in the operational

environment, the evaluator may develop test cases that specifically address the mission-related 4 needs of the user.

I- C:\Y2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page 15 Printed: 06/26/98 v.,

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

3 CPTL Year 2000 Compliance Project i

Evaluating Many Products Quickly When there are insufficient resources to exhaustively evaluate all the cataloged COTS /GOTS products, the evaluators must establish a prioritization scheme that can identify those products -

that may pose the greatest risk to the users' missions. Typical prioritization parameters will include:

i

• The importance,I, of the product to a specific mission. This can be estimated from

the functions the product performs explicitly or from the mission area that it supports.

Products that support mission critical areas potentially pose greater risk tha< ' hose in l support areas. Ican be assigned any convenient numerical range 4

l The pervasiveness, P, of the product in the user's environment. All other things being

equal, a product that is installed in large numbers poses more of a risk to the users missions than a product that exists as an isolated instance. P can be expressed as the -

! absolute number or copies of the product that are present, or as a fraction of the total i - number of copies of all products.

i a

The compliance level, Y, of the product as determined by an independent source or as claimed by the product vendor. Yranges from 0.0 (if the product is known not to be -

Y2K compliant) to 1.0 if compliance is definitely known. The level of compliance of l previous releases of the product may be considered in assigning a value to Y.

j The Y2K evaluation priority, R, for a product is then l R = I P (1 - Y).

l- Evaluation begins with the products of highest priority and proceeds downward until all products have been evaluated or until resources have been exhausted.

Caution / Evaluators should be alert to priorities derived from a compliance level claimed by a vendor. In these cases, some further investigation will be necessary to validate the general quality of the vendor's claims and the value of Y could be adjusted downward if necessary.

, Basic Test Cases

For all products that process dates, a set of basic date transition tests cases has been developed.

These are shown in Table 1.

4 j

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 16 Printed: 06/26/98

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

CP&L Year 2000 Compliance Project For these, or any other selected dates, it may not be necessary to execute a complete scenario for every transition. To determine this, the evaluator should examine the ways in which the system under consideration can fail as a result of a critical date transition:

. Crash

. Inunediate or short-term data cormption; or e Long-term or latent data corruption.

A crash occurs when the product (developed application, infrastructure, device or a combination) completely ceases to operate. In the Y2K context, this is most likely to happen at the Y2K transition (midnight,31 December 1999) because of the inability of one or more components to properly handle the new century. It is, of course, possible, but less likely, that a crash could occur as a result of the leap year transition or the transition to the year 2001. These latter transitions are more liable to cause data corruption of some sort.

Data corruption occurs when a product operates but fails to perform correctly one or more calculations required ofit. In the case ofimmediate or short-term data corruption, the results of the incorrect calculation (failing, say, to recognize Y2K as leap year and therefore computing the number of days between 28 February 2000 and 1 March 2000 to be 1) are visible soon after the error occurs and generally are of a transient and local nature (a bad display, for example). Long-term or latent data corruption, on the other hand, occurs when the results of an erroneous calculation are not detected quickly (often because they are not displayed or reported) and enter into the " database" where their effect on other systems (including those belonging to other organizations) may not be apparent for some considerable period of time (conceivably years).

Incorrect logistics or maintenance records are a possible example of long-term or latent data corruption.

Table 1-Basic Test Cases

• Test the setting and display of .

Test the processing of time-dates, including, as appropriate, data with different

- 1900/2/29 - should f all- data and not a leap - Use the current system clock

- 1996/2/29 - should then test with data 1996 is a leap dates before and

- 2000/2/29 - should after 2000 is a leap - Set the system clock

- 00/01/01 - should year 2000, say unambiguous 4 digit year test with data containing the value of which depends before 2000/01/01 and the application 2000/01/0 2000/01/01, - Set the system clock I

- 1999/12/31 - should be 2000/01/01 and test with ,

distinguish between regular containing dates of year 1999 date and a 2000/01/01 and af ter ]

meaning date (for never expiring date CAY 2K Project Documentation \905 Testing Guidelines Revised: 01/16/1978 l Page 17 Printed: 06/26/93

1 CPEL Year 2000 Compliance Project Next, the severity of the various failures should be estimated. Candidate categories of severity

_ are

l e Catastrophic;

• Serious;

• Inconvenient;  ;

e Other e

What constitutes each of these levels is, to a degree, a function of the nature of the product's l

purpose and functionality. However, some definitions can be att:mpted. A catastrophic failure may result in fatalities, serious economic loss, or complete mission failure. A serious failure will result in loss of data, and may require considerable time for recovery, with the attendant additional loss. A inconvenient failure has minimal or no operational consequences.

As a result of a Y2K failure analysis, the test dates in Table 1, and any others identified by the evaluator, that could result in some form of catastrophic failure should be selected as candidates for full testing. Those dates that could result in a failure of a lesser nature can be given a lower i priority'and the detail associated with the tests mn against them can be adjusted according to the degree of risk associated with the possible failures.

Layered Evaluation it is not always possible or even desirable to evaluate a product for Y2K compliance while it is in its operational configuration (that is, while connected to a complete system or system-of- ,

systems). There are several reasons for this but the primary ones are the complexity of the test and the fact that, at least for new developments, the final system is not available until very late in the development effort when error correction is difficult and expensive.

The best way to evaluate a product or set of products is to use a layered approach. That is, the product is tested as a stand-alone application, then in an isolated system, then finally in a system-of-systems environment.

Evaluating a product as an isolated application has the advantage that scheduling is relatively easy and test cases can be targeted specifically to functions performed by the product. The disadvantage is that the vulnerability of the product to non-Y2K information from another

- product cannot be completely determined since it is usually impossible to explore a really wide range of erroneous input that an interfacing application or system might provide.

Evaluating a product in a system environment provides some information on the effects it has on external systems. In particular is allows an evaluation of the compatibility of the product's Y2K approach with those of the other products in the same system. However the functioning of interfaces to remote systems is still a question, and it may be difficult to schedule time on a

. critical system for an extensive test.

Testing a product in a system-of-systems environment, particularly with life-like data, can be the ultimate source of compliance information. But it is difficult to coordinate and usually is expensive. Also, the functionality of the product being evaluated must be carefully examined. If C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 -

Page 18 Printed: 06/26/98

CPTL Year 2000 Compliance Project the product provides services that are, to a hign agree, intemal to a system, the knowledge gained by a system-of systems evaluation may not add sufficiently to the product evaluation to justify the high cost.

Isolating Systems for Evaluation When evaluating the operation of a product or system with another system that is not (or is not yet) Y2K compliant, it will be necessary to insert an intermediary function (often called a data bridge) between the two systems. This intermediary ensures that the system sees data that is Y2K consistent and that the external system sees data in the form it expects.

Depending on the nature of the test, the intermediary may limit its activities to simple format adjustments. If, however the test is intended to simulate operations near or after the Y2K transition, the intermediary will have to adjust actual date values from the external system to provide a futuristic environment and will have to alter the output of the SUT so that the external system sees data as it expects it.

In planning a test the evaluators must ensure that the users and administrators of the external systems are aware that the systems are being evaluated A Caution Before Testing  ;

Caution should be exercised when evaluating a product for Y2K compliance when the tests being executed involve simulating the near- or post-transition time frame. Abruptly advancing a system date will cause the product and the underlying infrastmeture (in particular, the operating system) to detect a quantum leap in time. Such a leap may cause things to " expire" and in ways that may not be reversible. For example:

I

=

iker ids and access privileges may expire, either because they have been programmed to elapse after a fixed amount of time, or because the system believes that the user (s) have not accessed the system for a long period of time and are, therefore, dormant.

Passwords may expire since most systems are set-up to require a change in passwords after fixed amounts of time, usually on the order of months. In some cases, setting the date back may undo the problem, in others, it may not.-

Data files and data bases may expire. Many systems will purge files (usually after an automatic archive, but frequently without warning) that have been untised for a set  ;

period of time. Abmptly advancing the date may trigger such logic, and the " damage" will likely be done before it is detected.

System authorizations and protections, like user ids may expire after a " quantum advance"in system time. Depending upon the mechanism used in purging such authorizations, this effect of date advancing may not be reversible.

)

CAY 2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 19 Printed: 06/26/98

CPEL Year 2000 Compliance Project Many licensed products are programmed with " time bomb" logic that cause them to become inoperable if the validity period of the license is exceeded. Once the license

. has expired, vendor assistance may be required to restore a product to usability.

Summary A good evaluation program is carefully planned in advance. It begins with a definition of Y2K compliance and uses a compliance checklist to keep itself and others informed ofits progress.

Further, the good program works continually and uses all information about a system or product, including requirements, design, code, and externally generated information.

Product evaluation is done in layers; first with the product alone, and then in more and more realistic configurations.

For any evaluation program where resources are limited, a risk-based strategy should be adapted that permits more thorough evaluations of those products that may have the most impact on the organization.

I i

l l

I i

l CAY 2K Project LoIEce.:c:icn\905. Testing Guidelines Revised: 01/16/1998 Page 20 Printed: 06/26/98

CP&L Year 2000 Compliance Project APPENDIX 1 - Common Date Dependent Non-Date Functions Many infrastructure products use the cate to perform what are essentially non-date functions.

Some of the most common ones are listed in Table 2. If these functions are important to the user's operational environment, then test cases must be developed that explore these areas in the near- and post-Y2K time frame. For example, many application-specific computer programs utilize temporary data files. If these programs make use of the operating system's file system for creation and deletion of these files, then it is important to ensure that they continue to operate j properly after the year 2000.

Table 2-Non-Date Functions Affected by Dates Major COTS /GOTS Category Date Usage l Operating Systems Names of temporary files l Data archiving Time and date values Passwords File management (archiving and purging)

Database Management Systems Date storage Date and time arithmetic  !

Mathematical Libraries Random number generation Date and time arithmetic Compilers Time /date-stamp object code Communications Date-Time-Group The list above is, of necessity, incomplete, since the number of ways dates can be used for non-date functions is limited only by the imagination of the product designers.

1 CAY 2K Project Documentation \905 Testing Guidelines Revised: 01/16/1998 Page 21 Printed: 06/26/98

l CPEL Year 2000 Compliance Project l APPENDIX 2- Year 2000 Compliance Checklist The purpose of this checklist is to aid in ensuring systems are compliant for the Year 2000. Make sure the following items are included in your Year 2000 testing and certification process.

Please respond to each question with the appropriate answer.

System Identification (An asterisk indicates an optional question)

1. Please provide system information.

a. Name of system

b. Operational date of system (current or a future date)*

c. Planned or actual replacement date of system (retirement or discontinuation qualifies as replacement)*

d. For planned replacements what is the contingency plan and under what conditions willit be invoked?*

e. What are the safety critical portions of the system,if any?*

C:\Y2K Project Dbumc.Itation\905- Testing Guidelines Revised: 01/16/1998 Page 22 Printed: 06/26/98

CP&L Year 2000 Compliance Project Year 2000 l

2. Each system has its own window of time, before and after the present date, in which it functions. Planning and scheduling systems work with dates that are weeks, months, and sometimes years in the future. Likewise, trend analysis systems and billing i systems regularly reference dates in the past. For your system, and its window of time, please verify its ability to successfully process data containing dates with no l

adverse effect on the application's functionality and with no impact on the customer '

or end user beyond adjustment to approved changes in procedures and data formats. I VERIFIED NO N/A

a. Dates in 20th century (1900s)

b. Dates in 21st century (2000s)

c. Dates across century boundary (mix 1900s and 2000s)

d. Crdsses 1999 to 2000 successfully i

~ '

C:\Y2K Project Documentation \900. Testing Guidelines Revised: 01/16/1998 l

Page 23 Printed: 06/26/98 i

CP&L Year 2000 Compliance Project Other/ Indirect Date Usage

3. Have you verified performance (and corrected if necessary):

VERIFIED NO N/A

a. Dates embedded as parts of other fields

b. Dates used as part of a sort key

c. Usage of values in date fields for special purposes that are not dates (e.g. using 9999 or 99 to mean "never expire")

d. Date dependent activation / deactivation of:

passwords, accounts, commercial licenses

e. Date representation in the operating system's file system (creation dates and modification dates of files and directories)

f. Date dependent audit information

g. Date dependencies in encryption / decryption algorithms

h. Date dependent random number generators

i. Date dependencies in firmware

j. Personal Computer BIOS and RTC does not reset the year to 1980 or 1984 on reboots after 31 December 1999 (corrections by operating system utilities allowed) l l

C:\Y2K Project Documentation \903- T: sting Guidelines Revised: 01/16/1998 Page 24 Printed: 06/26/98

i l

l l

CPicL Year 2000 Compliance Project {

l Leap Year

4. System accurately recognizes and processes Year 2000 as a leap year. l VERIFIED NO N/A

a. February 29,2000 is recognized as a valid date

b. Julian date 00060 is recognized as February 29,2000

c. Julian date 00366 is recognized as December 31,2000

d. Arithmetic operations recognize Year 2000 has 366 days Usage of Dates Internally

5. Internal application usage of dates and date fields must be clear and unambiguous in the context of the systems which use them. I VERIFIED NO N/A

a. Display of dates is clear and unambiguous (the ability to correctly determine to which century a date belongs either by explicit display, i.e. 4-digit year, or system or user inference)

b. Printing of dates is clear and unambiguous

c. Input of dates is clear and unambiguous

d. Storage of dates is clear and unambiguous

~

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 25 Printed: 06/26/98

CPtL Year 2000 Compliance Project External System Interfaces

6. External interactions are identified and validated to correctly function for all dates.

VERIFIED NO N/A

a. Interaction between this system and any other external time source, if existing, has been verified for correct operation.

For example, the GPS system is sometimes used as a time source.

Many GPS receivers cannot correctly deal with the roll-over of the GPS 10-bit epoch counter that will occur at midnight,21 August 1999. GPS receivers also deal with an 8-bit Almanac Week counter which has a 256 week roll-over span,

b. You and the responsible organization for each interface have negotiated an agreement dealing with Year 2000 issues.

For example, is the interface currently Y2K compliant, is it being worked on, does it have an unknown fix date, or will it be fixed by a future date you have mutually agreed on.

For each interface that exchanges date data, you and the responsible organizations have discussed and verified that you have implemented consistent Year 2000 corrections that will correctly work for date data passed between your systems.

' ~ ~

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 26 Printed: 06/26/98

-w- e er4 - r'm --c e w

CP&L Year 2000 Compliance Project Date Field Type

7. Describe the type of date fields used by the system, in either software or data bases.

4 VERIFIED NO N/A

a. Does the system use 4 digit year data fields?

1 b. Does the system use 2 digit year data fields?

c. If 2 digit, does the system use a century logic technique to correctly infer the century?

d. At what date will the century logic fix fail?

YES NO

e. Are-there any intemal data types for dates?

If yes to e, what is the range of dates that the date field can represent?

Minimum Date Maximum Date I

l i

C:\Y2K Project Documentation \905- Testing Guidelines Revised: 0i/16/1998 Page 27 Printed: 06/26/98

CP&L Year 2000 Compliance Project Year 2000 Testing Information

8. Optional: Please provide the following information with regard to testing the application for Year 2000 compliance: i Narrative Answer

a. Testing Organization

)

b. Name of Test Team Chief

c. Date that Year 2000 compliance testing was completed

d. How was Year 2000 compliance determined? (certified by vendor or ,

contractor, tested in-house, inspected but not tested, etc.)

YES NO

e. Are, the test data sets available for regression testing on the next version release for questions 2,3,4,5,6,7d, and 7e?

f. Are the detailed test results and reports available for review and audit for questions 2,3,4,5,6,7d, and 7e?

i l

l l

l I

C:\Y2K Project Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 28 Printed: 06/26/98

CP&L Year 2000 Compliance Project Off The Shelf Components

9. Optional: Please provide the following information with regard to off-the-shelf components.

YES NO N/A

a. Does the system use off-the-sheliapplication packages and/or infrastructure components?  !

b. If yes, have those items been verified to be Year 2000 compliant?

Narrative Answer l

c. How was Year 2000 )

compliance determined? I (certified by vendor or l contractor, tested in-house, etc.) l I

I i

1 l

C:\Y2K Project Documentation \905 Testing Guidelines Revised: 01/16/1998 Page 29 Printed: 06/26/98

..- .. .-. .- - . - -.-.- - . . . . . . - . - - ~ -

CPtL Year 2000 Compliance Project Certification Levels ,

Certification levels are defined below Yes, verified and N/A are considered positive responses, No is considered a negative response.

Level 0 System retired or replaced la Full independent testing completed with either:

- All questions have positive responses except possibly 7b and e Ib Full independent testing completed with either:

- All questions have positive responses except possibly 7a and e 2a Independent audit of system and existing testing completed with either:

- All questions have positive responses except possibly 7b and e 2b . Independent audit of system and existing testing completed with either:

- All questions have positive responses except possibly 7a and e 3 Self-certification CAUTION: Self-certification assumes a higher risk level of potential failures

'3a . Self-certification with full use of 4 digit century date fields

- All questions have positive responses except possibly 7b and e 3b' Self-certification indicates risk due to use of 2 digit century fields

- All questions have positive responses except possibly 7a and e 3c Self-certification indicates risk due to ambiguous usage of dates

- Question 5-a,b,c or d have negative responses.

3d Self-certification indicates potential problems (System needs additional work before Year 2000 processing can be assured with any level of reliability)

- Question 2-a,b,c or d have negative responses, pj:

- Question 3-a,b,c,d,e,f,g,h,i orj have negative responses, oJ:

- Question 4-a,b,c or d have negative responses, o_r

-_ Question 5-a,b,c or d have negative responses, or

- Question 6-a or b have negative responses, or

- Question 9-b has a negative response. i 4 Not certified or not certified yet.

1 I

i CAY 2K Project Documentation \905 Testing Guidelines Revised: 01/16/1998 Page 30 Printed: 06/26/98

CPtsL Year 2000 Compliance Project i

It would be advisable but not required for the team leader to have the responsible personnel fill out a similar checklist covering the products they are responsible for before completing this checklist for the overall application.

LEVEL OF CERTIFICATION FOR THIS DATA SYSTEM: (Circle only one)

Ola lb 2a 2b 3a 3h 3c 3d 4 I certify that the information provided above is true and correct to the best of my knowledge and belief:

ADDITIONAL COMMENTS:

Team Leader Date I cettify that the information provided above 4 true and correct to the best of my knowledge and belief:

ADDITIONAL COMMENTS:

Product Owner Date l

l l

~

C:\Y2id Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page 3i Printed: 06/26/98

CP&L Year 2000 Compliance Project Appendix 3: Year 2000 (Y2K) Compliance Test Plan for (Subject]

Introduction This document summarizes the minimum set of tests to be run on the [ Subject] to determine its current level of Year 2000 (Y2K) compliance. Additional testing and test situations will be determined by an analysis of the (Subject] operational requirements and ofits design.

Definition of Y2K Compliance In order to evaluate any system for Y2K compliance, we require a definition of compliance. That definition is composed of four parts.

Correctly process dates before and after 2000-01-01 For a product to be Y2K compliant, it must correctly process dates before and after 1 January 2000. This requires (to the extent that the (Subject] missions require it) that from the time the product is declared Y2K compliant until 1 January 2000, it must correctly process dates that are on either side of the millennium point.

After 1 January 2000, the product must continue to correctly process dates on both sides of the millennium point.

The product must correctly process 2000-01-01 itself.

Recognize Year 2000 as leap year To be Y2K compliant, the product being evaluated must recognize the year 2000 as a leap year.

This requires (to the extent that the [ Subject] missions require it) that

• Recognizing the date 2000-02 29 as valid.

I e Recognizing the (short) Julian date 00060 (sixty days from the start of the year) as 2000 29.

• Recognizing the (short) Julian date 00366 as 2000-12-31.

1

• Calculating the number of days between 2000-03-01 and 2000-02-28 as 2. l l

Accept and display dates unambiguously j To be Y2K compliant, the product being evaluated must receive, display, print, and store dates unambiguously.

C:\Y2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page 32 Printed: 06/26/98

CPEL Year 2000 Compliance Project Correctly process logic dates that are used for non-date functions To be Y2K compliant, the product must properly perform those non-date functions that have been implemented using date information. A non-date function is defined as a function performed by a system or component that, by its nature, does not require infonnation to satisfy its requirements. Many products, however, utilize dates and time to assist or control the execution of non date functions. Some examples of non-date functions that may use date information are:

. Information archiving functions

• Naming conventions e Passwords

• Random number generation As the list above indicates, most of these non-date functions are operating system related. Hence, few,if any such problems are anticipated vith [ Subject} software since the prc. 3r operator sessions,are assumed to be Y2K compliant. However, the tests will be run.

Critical Midnight Crossings To properly evaluate the (Subject) system for Year 2000, its behavior prior to, through, and after four critical midnight crossings must be examined:

• December 31,1999 to January 1,2000 -This is the basic millennium transition.

. February 28,2000 to February 29,2000 -This is the first of the leap year midnight transitions.

• February 29,2000 to March 1,2000 -This is the second of the leap year midnight transitions.

. December 31,2000 to January 1,2001 -This is the midnight transition that takes us beyond the Year 2000 situation.

Functional Operation Initial Conditions Before any testing, a complete system backup is required. This will include operational software, system and application files, and mission-related data.

This testing activity further essumes that all COTS /GOTS products, including operating systems, are current and are considered Y2K compliant by their vendors. ,

1 Operation Routine operation tests will consist of a set of exercises or [ Subject] system operations that require the (Subject] software to perform mission support functions exactly as would occur in normal operation. Each of these test situations will be run for each of the critical midnight crossings described above. As part of the test observations will be made of data presentations and displays as well as mission-related system functioning.

C:\Y2K doject Documentation \905. Testing Guidelines Revised: 01/16/1998 Page 33 Printed: 06/26/98

CPfiL Year 2000 Compliance Project Operation from N minutes prior to M minutes after Midnight The object of this test case is verification that the [ Subject] software can survive the critical midnight transition and to verify that, once the transition has occurred, the remainder of [ Subject]

date processing. This test case can be combined with the data entry verification case (below).

Enter Time /Date Dependent Data into system prior to Midnight and observe operation through Midnight crossing The objective of this test case is verification that time or date-dependent data entered into the (Subject] survive the transition and, after the transition, are processed correctly. This test case can be combined with the routine operation test case (above).

Additional Test Cases The test cases defined for evaluating the [ Subject] when operating through a critical midnight crossing and for ensuring that time- or date-dependent data are handled properly through the crossing are sufficient for many systems.

There ar'e some systems, however, that process dates in ways that require additional testing. For example, systems that make projections into the future or that analyze past data will require tests associated with those functions. Each such test will necessarily consist of four parts, one for each of the critical midnight crossings described above.

Further, if (Subject] has a data recording and playback capability, test cases must be developed that play back information recorded during each of the critical midnight crossings. These playback tests should consist of two parts: first, initiating a playback beginning sometime prior midnight and extending through the crossing, and, initiating a playback beginning after midnight.

Failover Operation A failover is defined as an event or situation that causes the master computer to a system to fail and the assumption of application processing control by a standby computer. For systems that employ a " hot standby" computer for use in case of the failure of the primary computer system, failover tests are necessary to ensure Y2K compliance of the total system. Systems that do not employ standby computers may omit failover test cases.

Failover test cases are not executed because one expects a failover to occur at the critical I midnight crossings (although they are possible), but because the takeover operations performed l by the standby computer frequently expose shortcomings in software design and implementation that routine test cases do not. In each case, the failover should be initiated as close to the midnight crossing as possible. The goal of the test is to force the standby computer to begin operation after the midnight crossing with data that was accumulated prior to the crossing.

CAY 2K Project Documen[stion\905- Testing Guidelines ' Revised: 01/16/1998 Page 34 Printed: 06/26/98 ,

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

I l

CP&L Year 2000 Compliance Project Test 1:

Midnight Crossing: December 31,1999 to January 1,2000 Situation: Routine Operation from N minutes prior to M minutes after Midnight Enter Time- or date dependent data item (s)into system prior to Midnight and observe operation through Midnight crossing The object of the first part of this test case is verification that the [ Subject] software can survive the critical midnight transition and to verify that, once the transition has occurred, the remainder of [ Subject] date processing.

The objective of the second part of this test case is verification that time- or date-dependent data entered into the [ Subject] survive the transition and, after the transition, are processed correctly.

Test Steps k

1. Restart [ Subject] system.

2. Set system date/ time to December 31,1999,23:50:00.

3. Observe general system operation.

4. Initiate data recording (if capability exists).

5. Identify " key parameter" or event and note time of occurrence Event: Time:

6. Generate time- or date-dependent data item Time- or date-dependent data it:m parameters:

7. Observe midnight crossing OK Not OK

8. Identify " key parameter" or event and note time of occurrence Event: Time:

1

9. Perform additional tests of date processing as required by system I characteristics.

10. Terminate test.

1 Was this test Y2K satisfactory? If other than "Yes," explain:

l C:\Y2K Project Documentation \905- Testing Guide;ines Revised: 01/16/1998 Page 35 Printed: 06/26/98

CP&L Year 2000 Compliance Project Test 2:

Midnight Crossing: February 28,2000 to February 29,2000 Situation: Routine Operation from N minutes prior to M minutes after Midnight Enter Time or date dependent data item (s)into system prior to Midnight and observe operation through Midnight crossing The object of the first part of this test case is verification that the (Subject] software can survive the critical midnight transition and to verify that, once the transition has occurred, the remainder of[ Subject] date processing.

The objective of the second part of this test case is verification that time- or date-dependent data entered into the (Subject} survive the transition and, after the transition, are processed correctly.

Test Steps i

1. Restart (Subject] system.

2. Set system date/ time to February 28,2000,23:50:00.

3. Observe general system operation.

4. Initiate data recording (if capability exists).

5. Identify " key parameter" or event and note time of occurrence Event: Time:

6. Generate time- or date-dependent data item Time- or date-dependent data item parameters:

1

7. Observe midnight crossing i OK Not OK

8. Identify " key parameter" or event and note time of occurrence l

Event: Time:

9. Perform additional tests of date processing as required by system characteristics.

10. Terminate test.

Was this test Y2K satisfactory? If other than "Yes," explain:

C:\Y2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page 36 Printed: 06/26/98

1 l

CPfL Year 2000 Compliance Project Test 3:

Midnight Crossing: February 29,2000 to March 1,2000 Situation: Routine Operation from N minutes prior to M minutes after Midnight Enter Time- or date-dependent data item (s) into system prior to Midnight and observe operation through Midnight crossing The object of the first part of this test case is verification that the [ Subject] software can survive the critical midnight transition and to verify that, once the transition has occurred, the remainder of [ Subject) date processing.

The objective of the second part of this test case is verification that time- or date-dependent data entered into the [ Subject] survive the transition and, after the transition, are processed correctly.

Test Steps

1. Restart (Subject] system.

2. Set system date/ time to February 29,2000,23:50:00.

3. Observe general system operation.

4. Initiate data recording (if capability exists).

5. Identify " key parameter" or event and note time of occurrence Event: Time-l

6. Generate time- or date-dependent data itern j

Time- or date-dependent data item parameters:

7. Observe midnight crossing OK Not OK

8. Identify " key parameter" or event and note time of occurrence Event: Time:

9. Perform additional tests of date processing as required by system characteristics.

10. Terminate test.

I Was this test Y2K satisfactory? If other than "Yes," explain. i i

CAY 2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page 37 Printed: 06/26/98

CPtL Year 2000 Compliance Project Test 4:

Midnight Crossing: December 31,2000 to January i,2001 Situation: Routine Operation from N minutes prior to M minutes after Midnight Enter Time or date dependent data item (s) into system prior to Midnight and observe operation through Midnight crossing The object of the first part of this test case is verification that the (Subject] software can survive the critical midnight transition and to verify that, once the transition has occurred, the remainder of[ Subject] date processing.

The objective of the second part of this test case is verification that time- or date-dependent data entered into the [ Subject} survive the transition and, after the transition, are processed correctly Test Steps X

1. Restart [ Subject] system.

2. Set system date/ time to December 31,2000,23:50:00.

3. Observe general system operation.

4. Initiate data recording (if capability exists).

5. Identify " key parameter" or event and note time of occurrence Event: Time:

6. Generate time- or date-dependent data item Time- or date-dependent data item parameters:

i l

1

7. Observe midnight crossing l

OK Not OK 1

8. Identify " key parameter" or event and note time of occurrence Event: Time:

9. Perform additional tests of date processing as required by system characteristics.

10. Terminate test.

Was this test Y2K satisfactory? If other than "Yes," explain:

Summary of Y2K Evaluation CAY 2K Project Documentation \905- Testing Guidelines Revised: 01/16/1998 Page 38 Printed: 06/26/98

NGG Year 2000 Readiness Program 29 APPENDIX H STANDARD CONTRACT LANGUAGE l

l I

l l

l CONFIDENTIAL INFORMATION FOR CPt8.USE ONLY 08/04/98

__ ~_ _ __

- - _ _ _ _ _ _ _ _ . . _ _ _ . - _ _ _ . _ - ._m _ _ _ _ _

STANDARD LANGUAGE FOR NEW CONTRACTS j YEAR 2000 PROBLEM Year 2000 Comoliant i

Contractor represents and warrants that on or before January 1,1998, that all computer environment related products (i.e. hardware, firmware or software) provided under this Agreement will, under normal use and service, record, store, process, and present calendar dates falling on or after January 1, 2000, in an accurate manner, and with the same performance and functionality, as those products record, store,

- process and present calendar dates on or before December 31,1999. Contractor warrants that products have been tested by Contractor to determine the products are Year 2000 compliant and that such test and 4

results will be documented and made available to CP&L upon request at no cost. Also, Contractor agrees to participate in any additional tests of the products at no additional charge to CP&L. Further, Contractor l warrants that the pmducts will lose no performance nor functionality with respect to the introduction of I

records or date data on or after January 1,2000 and warrants that the products will be operable with other products used by CP&L which may deliver records or date data to the products and/or computer 4

environment, receive records or date data from the products and/or computer environment, or interact l with the products and/or computer environment in the course of processing records and date data, i

Contractor warrants that all work and services performed under this Agreement shall be undertaken in a good and workmanlike manner. Contractor further warrants that the work shall be of good quality, free from defects or errors in design, programming, material and workmanship, and shall be fit for its

) intended use. If any failure to comply with this Agreement is discovered, the Contractor shall at its own expense correct the defect. The Contractor shall begin corrective work immediately upon notification of 7 the defect and shall continuously and diligently pursue the repair or corrective work until it is completed.

If CP&L notifies Contractor of a violation of this Agreement or defect and Contractor does not

immediately take all actions necessary to correct the violation or defect within the schedule required by CP&L, CP&L shall have the right to correct or employ others to do so, and Contractor shall be liable for all costs and expenses thereby incurred by CP&L. If either repair or replacement with another product is feasible and previous efforts to correct the item have failed, and CP&L desires the more costly alternative, the Contractor will proceed in accordance with the desires of CP&L.

1 Notwithstanding any provision in this Agreement to the contrary, Contractor agrees to indemnify and hold CP&L and its shareholders, officers, directors, employees, agents, successors, and assigns harmless from and against any and all claims, suits, actions, liabilities, losses, costs, reasonable attorney's fees, expenses, judgments, or damages, whether ordinary, special, or consequential, resulting from any third-

. party claim made or suit brought against CP&L or such persons, to the extent such claim or suit results 4

from Contractor's breach of the warranties contained herein.

Any provisions of this Agreement which limit or eliminate the liability of either party shall have no application with respect to the Year 2000 compliance warranty set forth herein.

Usage

! - Contractor hereby agrees that the products may be used by or for the benefit of any parent, subsidiary or affiliate of CP&L.

W

l l

1 i

1 Attention:

AGREEMENT NO.

AMENDMENT NO.

EFFECTIVE Ily this Amendment, the parties agree by the signature of their authorized representatives to change the terms of the above referenced agreement. This Amendment is based on the following understandings:

(hereinafter " Contractor" for this Amendment) recognizes and is fully aware of the Year 2000 problem associated with computer environments which include but are not limited to hardware, software and firmware. On January 1,2000, unless the computer environment is corrected, most such computer environments with time-sensitive programs will cease to accurately determine and apply the date. This situation could result in a crash of the entire environment and/or among other results produce performance and functionality problems which could adversely affect the business well being of Carolina Power & Light Company (hereinafter "CP&L" for this Amendment).

'Iherefore,in recognition of the above and the suia of $10.00 paid by CP&L to Contractor and other good and valuable considerations, the receipt and sufficiency of which are hereby acknowledged by Contractor as payment in full for the following:

1.

Contractor represents and warrants that on or before January 1,1998 that all computer environment related Products (i.e. hardware, firmware or software), hereinafter " Products" for this Amendment, provided under Agreement will, under normal use and 1 service, record, store, process, and present calendar dates falling on or after January 1, 2000, in an accurate manner, and with the same performance and functionality, as those  ;

Products record, store, process and present calendar dates on or before December 31,1999.

Contractor. warrants that Products have been tested by Contractor to determine the Products are Year 2069 compliant and that such test and results will be documented and made available to CP&L upon request at no cost. Also, Contractor agrees to participate in any additional tests of the Products at no additional charge to CP&L. Further, Contractor warrants that the Products will lose no performance nor functionality with respect to the {

introduction of records or date data on or after January 1,2000 and warrants that the Products will be operable with other Products used by CP&L which may delivery records or date data to the Products and/or computer environment, receive records or date data from the Products and/or computer environment, or interact with the Products and/or computer environment in the course of processing records and date data.

CSN: AMENDMENT '

(09 4S/95) i I

e29324

Page , Contract No. , Amendment No. _  ;

I 2.

Contractor warrants that all work and services performed under this Amendment shall be

]

undertaken in a good and workmanlike manner. Contractor further warrants that the work shall be of good quality, free from defects or errors in design, programming, material and {

I workmanship, and shall be fit for its intended use. If any failure to comply with this j Amendment is discovered, the Contractor shall at its own expense correct the defect. The ,

Contractor shall begin corrective work immediately upon notification of the defect and shall I continuously and diligently pursue the repair or corrective work untilit is completed.

If CP&L notifies Contractor of a violation of this Amendment or defect and Contractor does not immediately take all actions necessary to correct the violation or defect within the schedule required by CP&L, CP&L shall have the right to correct or employ others to do so, and Contractor shall be liable for all costs and expenses thereby incurred by CP&L If either repair or replacement with another product is feasible and previous efforts to correct the item have failed, and CP&L desires the more costly alternative, the Contractor will proceed in accordance with the desires of CP&L.

3.

Notwithstanding any provision in the above referenced Agreement to the contrary, j Contractor agrees to indemnify and hold CP&L and its shareholders, officers, directors, employees, agents, successon, and assigns harmless from and against any and all claims, )

suits, actions, liabilities, losses, costs, reasonable attorney's fees, expenses, judgments, or damages, whether ordinary, special, or consequential, resulting from any third party claim made or suit brought against CP&L or such persons, to the extent such claim or suit results from Contractor's breach of the warranties contained herein.

4.

Any provisions of this Amendment, Agreement or other Agreements which limit or eliminate the liability of either party shall have no application with respect to the Year 2000 compliance warranty set forth herein.

5.

Contractor hereby agrees that the Products may be used by or for the benefit of any parent, subsidiary or affiliate of CP&L All other terms in the Contract or other Contract Amendments remain unchanged. In the event of g any conflict between the terms and conditions of this Amendment and the terms and conditions of the Agreement . the terms and conditions of this Amendment shall prevail.

- next paragraph begins on the following page -

I I

CSN: AMENDMENT (99/05/95) e29324 1

Page , Contract No. , Amendment No.

Please execute this Amendment, retain a copy for your file, and return the original within ten (10) calendar days to

. Procurement & Contracting, Carolina Power & Light Company, P. O. Ilox 1551 (CPB 2C3), Raleigh, NC 27602.

Sincerely, J_

Accented:

Ily: -

Name (printed):

Title:

Date:

Should the person's title who is executing this document not indicate that he/she is a corporate officer, an >

affidavit signed by a corporate officer shall be provided stating that the person whose name appears above is duly authorized to execute Contracts on behalf of the firm.

CSN:Af,lENDMENT (09r05/95)

1. 29324