This document describes the test process that Detection Systems, Inc. has used to analyze, test and certify those products that successfully make the transition in date from December 31, 1999 to January 1, 2000 and beyond.

Goal: All products will be analyzed and tested according to this Year 2000 Test Strategy / Plan to verify conformity with Detection Systems' Year 2000 Compliance Definition.*

General information relating to Year 2000 compliance includes the following (where applicable):

• date on device can be set to high-risk dates
• device will perform as specified on high risk dates
• device date rolls over correctly on high-risk dates
• device date correctly used in time stamps for high risk dates - logs, file volumes, data saved on hard disks, reports, etc.
• days of week are represented accurately in the years 2000 and 2001
• device correctly recognizes that there are 366 days in the year 2000 (leap year)
• device accurately calculates duration when computing statistics, expirations, etc.
• a device that includes date based sort/merge utilities produce correct sequences across dates in 19xx and 20xx - logs, file stamps, reports, etc.

*Year 2000 Compliance Definition:

All applications, systems, software and hardware products manufactured and sold by Detection Systems and it’s subsidiaries, will function correctly when dealing with dates/times, and date/time related data in the following manner:

• The products will accurately process date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the 20th and 21st centuries, and the years 1999 and 2000, and leap year calculations.
• The products will neither contain nor create any logical or mathematical inconsistency, will not malfunction, and will not cease to function when processing date/time data after such products are certified by Detection Systems for year 2000 compliance.

Note: For a complete Year 2000 Compliance product report, please refer to our "Year 2000 Product Compliance Matrix."

This section outlines the strategy used by each product division to verify conformity / non-conformity with the Year 2000 Compliance Definition.

All applications, systems, software and hardware products manufactured by Detection Systems and its subsidiaries will be subjected to this Year 2000 Test Procedure.

The first step for each product is to determine if it is sensitive to Year 2000 issues. These products will hereafter be referred to as "Date Sensitive." The analysis of a product will be performed by a Test Engineer / Technician or a Development Engineer as appropriate.

For all products, the analysis strategy will be to start with the latest version of hardware, software and firmware. If the product passes the analysis, then no earlier versions will be specifically examined unless the engineer identifies a possibility that an earlier version of the product was date sensitive. (Note: It is not likely that a product with a real-time clock was subsequently removed). If the product is determined to have a date-sensitivity, then all versions will be tested.

Products that pass the analysis will be specifically re-analyzed with each new software release. However, as new features (hardware and software) are added to a system, System Test Engineering will analyze the impact on the system to determine which products (if any) will need to be re-tested. Software and firmware revisions will always be analyzed for any possibility that date sensitivity has been introduced.

1. Adjust real time clock to 11:55 PM, 12/31/99, wait 6 minutes, observe the new real time clock display / internal representation. Test product for correct mission critical operation.
2. Initiate events that would be placed in a history log and test chronological order of events in the log. If the log can be printed, observe correct printout. If the log can be uploaded to another application, upload and observe correct chronological order.
3. If the product has one or more local or remote applications that communicate or downloads date specific information, make sure that rolling the date from 12/31/1999 to 1/1/2000 (on the application not under test), or passing year 2000 date information does not corrupt the internal product database and that the new downloaded information is displayed accordingly.
4. Verify correct behavior of the automated features that are dependent on time, date, day of week, etc.
5. Test that real time durations still operate correctly.
6. If any product functionality is dependent on comparisons of dates, test this operation.
7. If the products are powered off in the year 1999 and powered on in the year 2000, will they indicate the correct day, date, and time? (if they provide provisions for maintaining battery backup of the real time clock operation)
8. If the products are powered off sometime after 1/1/2000 and powered back on, will they indicate the correct day, date, and time?

1. Adjust real time clock to 11:55 PM, 2/28/00, wait 6 minutes, observe the new real time clock display / internal representation. Test product for correct mission critical operation.
2. Initiate events that would be placed in a history log, test chronological order of events in the log. If this log can be printed, observe correct printout. If the log can be uploaded to another application, upload and observe correct chronological order.
3. If the product has one or more local or remote applications that communicate or download date specific information, make sure that changing the date on these products to 2/29/00, or passing year leap year date information does not corrupt the internal product database and that the new downloaded information is displayed accordingly.
4. Verify correct behavior of the automated features that are dependent on time, date, day of week, etc.

Rollover From December 31, 2000 to January 1, 2001

1. Verify rollover from 12/31/00, to 1/1/01. Implement a set of tests similar to those performed for the 12/31/1999 to 1/1/2000 rollover.

The following list of dates have been identified as having risk for erroneous operation:

Customers will be notified of any Critical Product Deficiencies in Year 2000 operation as soon as they are identified. Critical Product Deficiencies are defined as failures that seriously impact product operation, especially any failure that could result in life or property safety issues.

Corrective action plans will be included in the product notifications. The company at it’s discretion may take limited actions or no action on non-critical deficiencies.

At this time the company knows of no critical product deficiencies.

Any new product development will adhere to the Company's "Year 2000 Compliance Definition" as well as internal time, day, date and year design requirements.

Rev. 11/25/98