Year 2000 Product Evaluation Plan

Last Revised: 3/15/99. Will be continuously updated.

8/25/98 - Instrument Status: 8000/8000A/8000S (particle counter/sampler) - PASSED all applicable tests. PFC 200 (particle counter) - PASSED all applicable tests. CleanCount (particle counter) - PASSED all applicable tests.
9/23/98 - Instrument Status: Model 243A (airborne particle counter) - PASSED all external tests.
10/27/98-Addition of all sensors and samplers.
1/20/99-Logger Software

1. INTRODUCTION
2. HIAC Royco Y2K COMPLIANCE DEFINITION
3. HIAC Royco Y2K POLICY STATEMENT
4. TEST PLAN
4.1 WHAT TO TEST AND WHICH TESTS APPLY?
4.2 TEST PROCEDURES

5. TEST RESULTS
6. TEST PLAN COVERAGE CHECKLIST

1. INTRODUCTION

This document contains the general information about year 2000 problem. What is the definition of year 2000 conformance? Year 2000 conformity means that neither performance nor functionality is affected by dates prior to, during, and after the year 2000.

These problems can exist in any application at planning, execution, and control levels that use 2-digit year data structures. At 2000, the 2-digit structures may treat "00" as 1900 rather than 2000, causing incorrect calculations, system shutdowns, and/or malfunction.

The problem exists in software applications, operating systems, hardware, firmware, including programmable logic controllers (PLCs), various embedded computing systems, smart instruments with real-time clocks, robots, human machine interfaces to controls, and data historians for plant-floor processes. Systems such as materials management, execution, or maintenance application, automated tool cribs, and production process modeling tools also need to be assessed for year 2000 problem. Data acquisition and data-historian applications are date-aware and prone to year 2000 problems. Also, heavily automated systems often rely on local-area networks for dates and times, so network compliance may come into play.

2. HIAC Royco Y2K COMPLIANCE DEFINITION

Year 2000 conformity shall mean that neither performance nor functionality of HIAC Royco products is affected by dates prior to, during and after the year 2000. In particular:
1. No value for current date will cause any interruption in operation.
2. Date-based functionality must behave consistently for dates prior to, during and after year 2000.
3. In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules.
4. Year 2000 must be recognized as a leap year.

3. HIAC Royco Y2K POLICY STATEMENT

HIAC Royco’s general software policy is to no longer upgrade or enhance DOS-based programs. Because PDAS is DOS-based system, there are no plans to correct any year 2000 problems. It is anticipated that an upgrade to a new software package will be available by the year 2000, although no plans are yet in place to replace PDAS. The PDAS source code is available for customers who wish to continue to use and modify the software.

Since Logger also is a DOS-based program there are no plans to correct any year 2000 problems. If a problem is found, an alternative data logging program or instructions on how to use a standard commercially available program with HIAC Royco equipment, will be provided prior to the year 2000. This new program will be a Windows-based product and will need to run on a Microsoft Windows platform.

4. TEST PLAN

This section contains information about Year 2000 testing. This section is divided into two subsections. First subsection explains the "WHAT TO TEST AND WHICH TESTS APPLY" and second subsection describes the "TEST PROCEDURES".

The Section 6.0 "Test Plan Coverage Checklist" provide a comprehensive list of questions that can be used to review a test plan for completeness.

1. To determine the requirement for testing each application, the following factors are considered:
2. Does the system have a real time/virtual/system clock
3. Does the system display a date
4. Does the system print a date
5. Does the system store date information
6. Does the application connect and pass date information to other systems
7. Does the application run on an operating system that is not Year 2000 compliant
8. Does the application use a package that is not Year 2000 compliant
9. Does the application use a tool that is not Year 2000 compliant
10. Does the application use the date for scheduling or time stamps

4.1 WHAT TO TEST AND WHICH TESTS APPLY?

1. The devices that are part of the system and share date information or devices that use date information for product making in the manufacturing process (encoded date information) will be considered for testing.
2. Any product or system that prints dates (on screens or reports) will be checked for valid display and consistency of display.
3. A product or system which ‘stamps’ records with the current date and/or time, test will be devised to check that the record date/time information is written and interpreted correctly.
4. Any product or system that is required to respond in real-time to a time-based event (e.g., an alarm), will have tests devised to simulate time-based events.

See Table 1 for a list of all products to under go Y2K evaluation. Table 2 summarizes all test results.

Table 1: HIAC Royco products and their Year 2000 compliance verification testing requirements:

¹The description of tests A, B, C, D.... is in section 4.2.   The symbol "v" indicates applicable test and the symbol "x" indicates non-applicable test.
²Refer to section 3.0: HIAC Royco POLICY STATEMENT.

4.2 TEST PROCEDURES

The following test procedures are intended to provide a baseline for Year 2000 testing to ensure consistent and repeatable results. These tests apply to computer hardware, operating systems and associated software application products.The tester will review these tests and determine which apply to the specific component or system under evaluation.

A brief description of each test is provided for conducting tests on products with unknown status.

Results and products to be tested shown in Table 1 and Table 2.

4.2.1 CRITICAL DATE VALUES:

The following critical date values are chosen to test the functionality of the system for Rollover, Reboot and Leap year test. These dates and control sequences will be used to verify proper operation of the Unit Under Test (UUT):

1. 12-31-1998 Rollover, Reboot
2. 01-01-1999 Reboot
3. 12-31-1999 Rollover, Reboot
4. 01-01-2000 Reboot
5. 02-28-2000 Leap Year Rollover, Reboot
6. 02-29-2000 Leap Year Rollover, Reboot
7. 03-01-2000 Reboot
8. 12-31-2000 Rollover, Reboot
9. 01-01-2001 Reboot
10. 02-28-2001 Leap Year Rollover, Reboot
11. 03-01-2001 Reboot
12. 02-28-2004 Leap Year Rollover, Reboot
13. 02-29-2004 Leap Year Rollover, Reboot
14. 03-01-2004 Reboot

The following test procedures provide step by step instructions for performing each test.

4.2.2 External Tests: (User’s point of view)

Discussion: The following 4 tests (A to D) address Y2K issues and concerns from a user’s point of view. These tests can be performed externally without changing the software. Users can easily perform the following tests by setting different date & time values.

A. Manual Date Set Test:

Discussion: This test checks the correct date & time entry to initialize the system clock. Some PC’s revert to a default date (1980 or 1984) when set to a date in the year 2000. Some systems have multiple date setting functions; for a PC the date may be set using the CMOS Setup program at power on, using a DOS date function, or using a windows clock or control panel interface. If the equipment has a battery backed up clock, the date set test must include removing both battery power and external power to completely initialize the system clock and attempt to set the date to 1 Jan 2000. This testing sequence ensures that setting the date and time occurs in both the systems virtual and real time clocks.

Procedure:

1. Date Set
Manually set the date to 1 Jan 2000 & time to 00:01:00 and verify through observed recall.

2. Date retention
With the date still in the year 2000, power down the system.
After approx. 1 minute, power up the system and verify the proper date & time has been retained.

3. Date Set
Manually set the date to 29 Feb 2000 & time to 00:01:00 and verify through observed recall.

4. Battery Removed Tests
Run only if system has a secondary power source for time keeping. This date set test must include removing both battery power and external power to completely initialize the system clock.

Manually set the date to 1 Jan 2000 & time to 00:01:00 and verify through observed recall. Now, remove the battery and give enough time (5 minutes) for the battery backed up circuits to discharge (e.g., 47uF capacitor charged to 5V needs at least 30 seconds to discharge with a 10uA load.). After discharge, verify the date & time did not properly advance during the discharge period. Reinstalled the battery and power up the system. Manually set the date to 1 Jan 2000 & time to 00:01:00 and verify through observed recall. Cycle power off for 5 minutes and verify the date 1 Jan 2000 & time was retained and properly advanced.

Exercise caution to document all system configurations when attempting this test because the configuration may be lost upon removal of the battery.

B. Rollover, Reboot Test:

Discussion: The Rollover test checks for proper handling of the date transition from year 1999 to 2000 without manual intervention.

Procedure:

1. Rollover - 1999 to 2000 - Power on
Set the date to 31 Dec 1999 & time to 23:59:00 (11:59 p.m.) and, observe the system date & time after 00:00:00 a.m.

2. Rollover - 1999 to 2000 - Power off
Set the date to 31 Dec 1999 & time to 23:59:00 (11:59 p.m.) and, power down the system before it can roll over to year 2000.
Wait until after 00:00:00 a.m. with the power off. Then, power up the system and, observe the system date & time.

Discussion: The reboot test checks for correct date & time storage during power cycles of the system.

Procedure:

3. Reboot - Date retention
Set the date to 1 Jan 2000 & time to 00:01:00. Then, power down the system. Again, power up the system and, observe the system date & time.

C. Leap Year Test:

Discussion: The leap year test checks the logic that calculates valid dates for leap year. 2-digit year representation presents possibility of divide by zero problem. The following are leap year considerations:

1. If the year is divisible by four, it is a leap year;
2. If the year ends in 00, it is not a leap year;
3. If the year is divisible by 400, then it is a leap year;
4. If the year is 3600, it is not a leap year.

Procedure:

1. Leap Year - Rollover 2/28 - Power On
Set the date to Monday 28 Feb 2000 & time to 23:59:00 (11:59 p.m.) and, observe the system date after 00:00:00 a.m. (The date should be Tuesday 29 Feb. 2000)

2. Leap Year - Rollover 2/28 - Power Off
Set the date to Monday 28 Feb 2000 & time to 23:59:00 (11:59 p.m.) and, power down the system before it can roll over to 29 Feb. 2000.
Wait until after 00:00:00 a.m. with the power off. Then, power up the system and, observe the system date.

3. Leap Year - Reboot 2/29
Set the date to 29 Feb. 2000 & time to 00:01:00. Then, power down the system. After approx.1 minute, power up the system and, observe the system date. (The date should be Tuesday 29 Feb. 2000)

4. Leap Year - Rollover 2/29 - Power On
Set date to Tuesday 29 Feb. 2000 & time to 23:59:00 (11:59 p.m.) and, observe the system date after 00:00:00 a.m. (The date should be Wednesday 1 March 2000)

5. Leap Year - Rollover 2/29 - Power Off
Set the date to Tuesday 29 Feb 2000 & time to 23:59:00 (11:59 p.m.) and, power down the system before it can roll over to 01 Mar. 2000.
Wait until after 00:00:00 a.m. with the power off. Then, power up the system and, observe the system date.

6. Other Tests
Applying same test procedure above, verify that Year 2001 is not a leap year and Year 2004 is a leap year.

D. Input/Output Data Test:

(I) Input Data Test:

Discussion: The input data test applies to systems that read date information from labels or other control systems (e.g., keyboard, bar code scanner, remote host, etc.).

Procedure:

1. Set the date of the UUT date by using standard input (Keypad) to January 1, 1999 & time to 00:01:00.
2. Create input labels or simulated inputs by using the alternate input from the other systems with a date 01-01-2001 (or 01-01-01) as required.
3. Verify that the system correctly reads the input date.
4. Record the results for each input channel.

(II) Output Data Test:

Discussion: The output data test applies to systems that write date information to labels or other control systems (e.g., display, print on the screen, plotter, etc.).

Procedure:

1. Set the date of the UUT date to January 1, 2001 & time to 00:01:00.
2. Output the date & time information. Verify that the UUT correctly outputs the date & time and the application accepts/displays the date & time correctly.
3. Record for results for all applicable output channels.

4.2.3 Internal Tests: (Programmer’s point of view)

Discussion: The following 7 tests (E to K) address Y2K issues and concerns from a software engineering point of view. In the existing software, the following tests will be performed by programmer as required.

E. Date Window(Century)Tests:

Discussion: This test applies for input values 00-99 to determine which century is assumed. Windowing date systems assume the first 2-digits of a 4-digit year to be 20 for values below a switch value and 19 for values above or equal to switch value. e.g., A switch value of 50 provides for a range of 1950 to 2049. If the 2- digit year is equal to or greater than 50, the year is assumed to be 19xx and if the 2-digit year is less than 50 the year is assumed to be 20xx. i.e. 84 is greater than the switch value, so the year is 1984 and 34 is less than the switch value, so the year is 2034. When two integrated systems share date information in this format be sure to test the interface at the boundary conditions.

Systems using date windowing should consider testing:

1. Creation of date data at the switch boundary dates, above and below;
2. Modification of configurable windowing parameters, i.e. change the switch value;
3. Modified switch boundary dates, above and below.

Procedure:

1. Date Window Test - Below Limit
Determine the switch value.
Change the current date to one year below the switch value.
Observe a 4-digit date. ( The date assumes 20xx.)

2. Date Window Test - Above Limit
Change the current date to one year above or equal to the switch value.
Observe a 4-digit date. ( The date assumes 19xx.)

3. Date Window Test - Change Limit
Change the configurable switch value to 2004.
Observe the configured switch value.(Limit has been changed to 2004)

4. Repeat the above and below limit tests to confirm the limit has changed. Record the switch value and conditions.

F. Date Calculation Test: (Arithmetic Data Tests)

Discussion: If dates are used in any calculations in software, test for correct operation. e.g., a testing system uses a 2-digit year date format and keeps the last calibration date & calibration interval. Before each execution of the test application, the software calculates the next calibration date (last calibration date + calibration interval) and compares the current calibration date to the next calibration date.

Procedure:

1. Days in 2000
Create a period calculation using 1-Jan-2000 as the start date and 31-Dec-2000 as the end date. (The year 2000 has 366 days and checks that 1-Jan-2001 will be Monday)

2. Days across 1999/2000 Boundary
Create a period calculation using 1-Dec-1999 as the begin date and 31-Jan- 2000 as the end date. (The period has 61 days.)

3. Days across leap year
Create a period calculation using 1-Feb-2000 as the begin date and 1-Mar- 2000 as the end date. (The month of February has 29 days.)

4. Other Tests
Applying same test procedure above, verify that in year 2001, February has 28 days and in year 2004 February has 29 days.

5. Identify and record the locations within the UUT’s software where this test exercised.

G. Data storage Test:

Verify that the data storing and retrieving from memory or any storage place are year 2000 compliant.
e.g., Sorting and merging, Searching, Indexing on disk file or database table, Moving data within primary memory.
Identify and record the locations within the UUT’s software where this test exercised & also record the results.

H. Timer Test:

Discussion: This test verifies the proper operation of event timers within the UUT.

Procedure:

1. Set the date of the UUT prior to 2000.
Set a timer to wake up, alarm, or trigger at 10:01 AM, January 3, 2000.

2. Set the date of the UUT to January 2, 2000.
Create new timer to wake up, alarm, or trigger at 10:02 AM, January 3, 2000.

3. Set the date of the UUT to January 3, 2000.
Set the time to 10:00 AM.
Wait for the alarms to trigger.
It verifies that the alarm or timer created before and after 2000 operates correctly.

I. Delay Test:

Discussion: This test verifies the delay routines in software.

Procedure:

1. Test the delay routine in software for checking year 2000 compliance. Verify that it works correctly.
2. Identify and record the locations within the UUT’s software or in subroutines where this test exercised & also record the results.

J. Display Data Tests:

Discussion: The display data test applies to systems that display date information on several different pages. The test must include moving the date ahead to the year 2000 and observing every screen that the controller contains. The reason for this test is that the different software may be written by different persons.

Procedure:

1. Create a list of all the date fields on all the display screens.
2. Set the date of the system under test to a date beyond January 1, 2000.
3. Create new files or fault records.
4. Attempt to display all date fields on all display screens for file dates or fault time stamps.
5. Verify that each date field display correctly.

K. Indirect Date Usage Tests:

Discussion: These tests apply to systems that use date information in indirect manner. The following list is intended to stimulate questions about a system that could use the date in functions that do not require date information, but may have been implemented using a date function.

Procedure:

Identify functions that use the date indirectly and verify correct operation for the year 2000.

e.g., encryption and decryption algorithms, random number generators, communication protocols.

4.2.4 Miscellaneous tests:

Discussion: The following 2 procedures address the need to re-evaluate the adequacy of the previous tests based on acquired software that manipulates data and/or makes decisions based on date and time I/O.

L. Language library:

Discussion: Tests should be done to verify the Year 2000 compliance of the programming language library (e.g. C, Motorola 68000 family).

Procedure:

Identify and record the locations within the UUT’s software where this test exercised & also record the results.

M. Purchased routines:

Discussion: All the purchased routines should be checked to see if they directly or indirectly have or use date and/or time I/O. If there is no way of evaluating the routine in question, contact the manufacturer for information.

Procedure:

Identify and record the locations within the UUT’s software where this test exercised & also record the results.

5. TEST RESULTS

Table 2: HIAC Royco products and test results.

³The description of tests A, B, C, D....is in section 4.2.  The "NT" indicates Not Tested test, the symbol "x" indicates non-applicable test. "P" indicates PASS for a test and "F" indicates FAIL for a test.
⁴PharmSpec test result:Although internally the program correctly handles the rollover, the display and printed reports exhibit formatting problem, while displaying and reporting 0/0//10 by PharmSpec upon rollover.

⁴Logger test result: Logger software if not a Y2K comliant because of the following minor issue: Logger function "Set Time", lets you set the time and date, that are used for tagging incoming data. With a Y2K, Logger displays the date incorrectly for 20xx.   It displays "01/01/10" instead of "01/01/00" for year 2000.   This is the only Logger feature that is not Y2K compliant. Work around: Outside of Logger use WINDOWS of  DOS to set the date.  NOTE: There are no plans to correct any year 2000 problems in Logger.  It will be replaced by the new product.
⁵PharmSpec S/W version 1.3 test result: Year 2000 ready with minor issue: In historical report design, the starting date and ending date comparison is not correct for Year 2000. e.g. If you enter the starting date of 01.01.99 or 12/31/99 and ending date of 01/01/00, then it will give an error that "Ending date must be greater than or equal to starting date." This is the only cross century file management issue that makes this software not fully Y2K compliant.
⁶See Page 23 for the Samplers listing and test results.
⁷See Page 24 for the Sensors listing and test results.

6. TEST PLAN COVERAGE CHECKLIST

Discussion: Questions about HIAC Royco Y2K product evaluation. The following list of questions was addressed when developing this test plan for validating a product’s state of Y2K compliance.

1. What are the results by version or release number of the software/hardware products that we have already tested for year 2000 compliance?
2. Does this product have a clock(time) function and has an internal date functionality?
3. Does this product use 2-digit year representation for date? If yes, is there support logic for year 2000?
4. Does this product use 2-digit year for display and print, for storage and as an input/output?
5. Does the product provide a function to obtain the system date from a host or through a time service?
6. Are there third-party products embedded in our product’s application?
7. Does the code ignore values for the explicit first 2 digits of year in the date or at any point in the program logic?
8. Does the application make a leap-year calculation? Do these calculations treat leap year properly? (2000, 2001, 2004)
9. Does our product perform date calculations?
10. Does our product have date fields or date-related variables in the programming code?
11. Does the application use assigned values for the date from one variable to another?
12. Does our product use the computer operating system date within calculations or comparisons?
13. Does our product use common date routines?
14. Does our product currently process dates beyond the year 2000?
15. How far into the year 2000 do the dates extend?
16. Do date fields require expansion from 2-digits to 4-digits, in our product on screens, on reports, within programs etc..?
17. Does our product interface with other vendor’s products?
18. Does our product support a data type for date values in the range 01-01-1980 to 12-31-2050 or more?
19. Are there any hardware attachments to the application that handle/use date & time? e.g., some systems may require use of bar code scanner.
20. Are the first 2-digits of the value truncated during any assignment?
21. Is the value in the target variable eventually used in a date manipulation that requires the explicit 4-digit value for correct results?
22. Are constants for date values (including month, day, year) used in any manipulation in our products?
23. Does the application store and retrieve dates accurately in our products for values in the range 01-01-1980 through 12-31-2050 or more?
24. Does any input channel like, bar code scanner scan or read any date information from our product or system?
25. Do all the date representations, both internal to the application and in all interfaces, satisfy the criteria for date compliance?

Samplers Test Results:

Sensors Test Results: