Method for limit checking

Details Method for limit checking Method for limit checking

1999-08-10

2002-07-02

Hoff, Marc S. (Department: 2857)

Data processing: measuring, calibrating, or testing

Measurement system

Measured signal processing

C356S071000

Reexamination Certificate

active

06415246

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to an automated testing system. More specifically, the present invention relates to a method for validating test measurements for an optical entity.
BACKGROUND OF THE INVENTION
In a submarine optical communication system, optical signals transmitted through the submarine optical fiber cable become attenuated over the length of the cable, which may stretch thousands of miles. To compensate for this signal attenuation, optical repeaters are strategically positioned along the length of the cable.
Moreover, optical signals transmitted through the submarine optical fiber cable must sometimes be transferred to a branching cable. To accomplish this task, optical branching stations are positioned at necessary locations along the length of the cable.
Submarine optical repeaters and branching stations must be designed to protect against the hazards presented by harsh undersea environments. These hazards can include corrosion, erosion, wide ranging seawater pressures and temperatures, and mechanical damage due to earthquake shocks, biological attack, and fatigue. Moreover, because of the difficulties associated with their delivery and installation, and the criticality of their telecommunication function, submarine optical repeaters and branching stations are typically designed to have relatively long, and maintenance-free operating lives.
Moreover, devices such as optical repeaters and branching stations are typically tested to verify that they have been manufactured according to specifications. These tests can be automated. Known automated testing systems can employ computer hardware and software to drive instruments that make measurements of a device's performance in response to changes in an independent variable. Some measurements can be gathered simply for informational purposes. Other measurements can be checked, or validated, against a set of limits. If all the measurements requiring validation pass, the device is deemed acceptable and shipped to the next stage of production. If any measurements fail validation, the device is typically sent to the test engineer for investigation.
Known automated testing systems are designed to vary only one independent variable before each repetition of a test. After making such a variation, a dependent or “test” variable is measured to determine the effect of the variation of the independent variable on that test variable. Thus, the known automated testing systems assume that all test variable measurements are discrete points and are not dependent upon an array (or arrays) of independent variables. For simple tests this can suffice. However, some devices require that more than one independent variable be changed simultaneously, resulting in a multidimensional nature to the measurement data. Yet, the data structures of the known automated testing systems are incapable of handling multidimensional data. Thus, there is a need for an automated testing system that can simultaneously vary more than one independent variable, and can collect, store, and report test variable measurement data related to those variations.
Also, in the known automated testing systems each test is responsible for validating its measurements as they are made. Thus, for each test, the programmer of that test's script must build routines that obtain limits and compare them to corresponding test variable measurement values as those values are collected. Since each test is responsible for validation, each test script programmer typically develops a somewhat unique way to perform the validation. Moreover, each test script programmer often develops a unique method for naming the elements of the data structure that contain the test variable measurement values and the limits used to check those values. Thus, there is little standardization among test scripts or their data structures, and therefore modifying a test script, particularly an older one for which the original programmer is unavailable to assist, can be a challenging endeavor.
Additionally, because the method for applying limits is programmed into the test script at design time, there is no opportunity to change that method after the release of the test script without reworking and recompiling the test script's code. For example, if measurements that were previously gathered simply for information purposes now need to be checked against limits, the source code for the test script must be modified, rebuilt, and re-released.
Moreover, in the known automated testing systems, because the validation or limit checking routines are integral to the test scripts, measurement data can only be checked at the time of testing. Due to this coupled nature of measuring and validating, if limits change, product must be retested to determine if it meets the new limits.
Furthermore, the limit checking portions of the known automated testing systems determine the limit values to apply to the test variable measurement data based on a wide variety of schemes, including:
Explicitly defined minimum and maximum values;
Nominal value with a +/− tolerance;
Nominal with a positive tolerance and separate negative tolerance;
Nominal with a +/− percentage; and
Nominal with a positive percentage and separate negative percentage.
The specific scheme is hard-coded within the local limit checker. If the test script programmer assumed a balanced +/− tolerance, and later it is determined that a different value is needed for the positive and negative terms, the original source code must be reworked, rebuilt and re-released.
The known automated testing systems require that limits be provided for each and every value of the independent variable used during the test. For example, if measurements are made at 32 points and the operator wants to check the test variable at only the endpoints (points #1 and #32), limits must be provided for all 32 points (resulting in thirty extra lines in the file to be maintained by the test engineer).
Because of measurement error it is possible for a measured value to appear to fall within the specified limits when in actuality, if the measurement were repeated several times, the average measured value would fall outside one of the limits. Thus, the limits used by the automated testing system should account for measurement error. However, the known automated testing systems do not provide a means for adjusting the limits, but instead expect the limits provided to the automated testing system to be adjusted for measurement error beforehand. Yet the error for a measurement can vary from one batch to another, and from one independent variable value to another, so a global change to the limits would not suffice.
Known automated testing systems are unable to check measurement data against non-numeric limits. For example, some instruments return hexadecimal numbers, such as A4D9. Other instruments indicate status or measurement results via LED indicators that glow in colors such as red, green, yellow, or blue. However, because the known automated testing systems do not allow non-numeric data to be checked against non-numeric limits, the information provided by these instruments must be converted by the operator into a numeric value before entry and limit-checking. This conversion process can be time-consuming and error-prone.
SUMMARY OF THE INVENTION
Embodiments of the present invention provide a method for validating test measurements. The method includes building an object that includes a test variable value, and a limit related to the test variable value, comparing the test variable value against the limit, and indicating if the test variable violates the limit.


REFERENCES:
patent: 4761748 (1988-08-01), Le Rat et al.
patent: 5500941 (1996-03-01), Gil
patent: 5764726 (1998-06-01), Selig et al.
patent: 5862477 (1999-01-01), Wellard et al.
patent: 5870667 (1999-02-01), Globuschutz
patent: 6061021 (2000-05-01), Zibell
patent: 6088588 (2000-07-01), Osborne
patent: 6175560 (2001-01-01), Bhagalia et al.

Affiliated with

Also associated with

Rating

Method for limit checking does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method for limit checking, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for limit checking will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2885477