A Behavior Model for Next Generation Test Systems.
Defining information required by automatic test systems frequently involves a description of system behavior. To facilitate capturing the required behavior information in the context of testing, a formal model of behavior was developed for use by test systems. The approach taken in defining the behavior model was based on information modeling and was derived from recent work in formal methods by the hardware and software design communities. Specifically, an information model was developed in EXPRESS capturing the relationships between essential entities characterizing behavior. In this paper, we provide a high level description of the behavior information model and several examples applying the model in a test environment.
INTRODUCTION
Defining information required by automatic test systems frequently involves a description
of system behavior in one way or another. Behavior is a characteristic of an entity that describes
how that entity acts or reacts within some context or environment. Within the context of test
systems, behavior is defined by what is observed as a result of testing.
Recent work in defining an architecture for next generation test systems has determined
that behavior descriptions are relevant in at least five contexts: 1) characterizing expected
behavior by the product, 2) defining test requirements, defining resource capabilities and
requirements, defining behavior of test strategies, and 5) guiding system diagnostics. To
facilitate capturing the required behavior information in each of these contexts, an information
model defining behavior has been developed. In this paper, we provide a high level description of
the behavior information model and several examples applying the model in a test environment.
Specifically, we focus on applying the model to capturing test requirements and resource
capabilities.
The approach taken in defining the behavior model is derived from recent work in formal
methods by the hardware and software design communities (Cook, 1992; Hall, 1990; Thomas,
1993). Formal methods are mathematically-based languages used to capture essential attributes of
a system being designed. These methods are used, typically, to guide the process of design
verification and proof-of-correctness. As such, most formal methods apply a "declarative"
approach to specifying systems. Declarative approaches specify systems by stating logical
properties and relationships among entities within the system (Abramsky & Hanking, 1987;
Hogger, 1984). The process of instantiating such a design corresponds to assigning legal values to
parameters within the system description such that the properties and relationships defined by the
description are consistent.
The approach taken in defining the behavior model was to develop an EXPRESS
information model capturing the relationships between essential entities characterizing behavior
10303-11:1994). The approach is declarative in that, in the
simplest case, the process of using the behavior model consists of matching an implementation to
a model to verify that the two correspond to one another. Thus, in the case of selecting an
appropriate resource to perform a test, a model of the required behavior is instantiated and
compared with a model of the possible behaviors provided by each available resource. The
resource is selected that matches the required behavior.
In the following sections, we discuss a simplified view of the EXPRESS behavior model
as well as a slightly more detailed view. This discussion is put in the context of a trivial test
program to highlight and describe the major entities of the model. Following this introduction, we
provide several examples using the behavior model in the context of test requirements, test
program synthesis, resource behaviors, and triggers or events.
A simplified view of the behavior model is shown in Figure 1. This simplified model will
be expanded later, but it is sufficient to explain the basic concepts. There are five entities in this
model.
1. location captures where something happens. In the current model, location can
be ports on or in a unit under test (UUT) or cells in a UUT.
2. behavior captures when something happens. This entity is distinct from the whole
behavior model in that it is limited to identifying a span of time over which something
occurs. This entity is defined by its start and stop attributes.
3. signal captures what happens. Types of signals include the DC_SIGNAL and
AC_SIGNAL, as well as standard programming data types, e.g., integer, real, or
boolean.
4. constraint defines rules constraining or restricting which values may appear on
signals.
5. time exists in the model solely to support the definition of the behavior entity. It
is a subtype of the property entity (defined below) and is used to "type" the
start and stop attributes of behavior.
The behavior model can be used to describe requirements on a test program and capabilities of a
test resource.
time constraint
location
behavior signal
start stop
when where
constrains

Figure

1. Simplified Behavior Model
A more detailed view of the behavior information model is shown in Figure 2. In this
figure, the five entities from Figure 1 are shown plus several additional entities capturing
constraint information. Significant in this figure is the observation that a behavior can be a
composite of lower-level behaviors, ultimately containing zero or more signals. Both
behavior and signal are characterized by a set of properties, each of which can be
constrained in some way. Further, in addition to constraints being applied to signals,
constraints can also be applied to behaviors. Finally, the current version of the behavior
model identifies four types of constraints: range constraints (limiting a property to lie
within some range of legal values), accuracy constraints (identifying the acceptable variation of
a property value from a specified reference), timing constraints (indicating legal ordering or
timing relationships with respect to another variable), and value constraints (indicating possible
legal values, such as discrete values). Arbitrary relationship constraints can be defined in the
constraint supertype without the need to instantiate one of the subtypes.
At first glance, it appears that the behavior model describes, for example, how a test
program must execute. This is almost, but not quite, correct. The behavior really provides a set of
criteria by which one can determine if a test program executed properly. To see why this
distinction is important, consider a UUT with two power supplies that may be used to establish
type
time
constraint
behavior
signal
start
property timing
range
accuracy
stoplocation
includes
constrained_by
has s[0:?]
props s[0:?]
props s[0:?]
location
location
constrained_by
value

Figure

2. Detailed Behavior Model
power once the ground has been established. No testing may be done on the UUT until after the
power supplies have been established. This situation is shown in the flow chart in Figure 3.
The branches labeled "PS 1" and "PS 2" can execute concurrently or sequentially-the
only constraints are that the branches cannot begin until "establish ground" is complete, and that
"run tests" cannot begin until both power supply branches are complete. Now consider a
hypothetical test program. Because the test program is sequential, it might look something like the
establish ground
establish PS_1
establish PS_2
run tests
If the "establish PS_x" routines can be decomposed into a more basic set of statements
(consisting, for example, of setup and apply statements), then the following version of the
program is also legal.
establish ground
setup PS_1
setup PS_2
apply PS_1
apply PS_2
run tests
There are many different legal execution paths that may be taken by a test program. It
would be inappropriate for a behavior specification to state that exactly one of those paths is
correct and all others incorrect. Such an approach would improperly restrict other legal paths 1 .
The behavior model describes the desired result of a test program rather than the test
program itself. The previous example provided pseudo code for a test whose objective was the
verification of a specified behavior. If the example was executed, real signals would be generated
1 However, there may be compelling administrative reasons to insist upon a particular order, e.g., procedural
reusability or test consistency.
establish
ground
run tests

Figure

3. Flow Chart for Providing Power for Tests
by the test equipment and applied to the UUT, and real signals would be observed or measured.
Ultimately, the behavior model specifies requirements on those signals.
Suppose, following execution of a test program, a complete record of all signals at the
interface to the UUT is available. For the sake of discussion, assume these signals have been
recorded with infinite precision. This record is called an execution trace of the test program. For
the example above, the execution trace would include the voltage and current at the ground and
power supply pins of the UUT. After a test program has executed the execution trace can be
examined to see what the voltages were at any time during the test.
The behavior model only defines constraints on the execution traces. The constraints are
not applied directly to the test program-they only influence decisions made in configuring and
executing the test program. The model is a "declarative" representation of behavior and does not
explicitly prescribe the behavior of the test program as might be expected from an imperative
(e.g. procedural or functional) description. Instead it describes the behavior that is expected from
the program.
A psuedo-language invented for illustration purposes is used to demonstrate the structure
of a behavior model and associated properties of behavior. Behavior is a class; therefore, each
instance of a behavior has a name. The declaration of behavior may include other behaviors (i.e.,
sub-behaviors) as well as signals, constraints, and other properties. The format used for our
pseudo-language is as follows:
<behavior-name>:
<property definition>
The property definition may include sub-behaviors, signals associated with the behavior and their
locations, and constraints defined on the behavior or any of its properties. In the following
discussion, this pseudo-language will be used to present several example declarative fragments.
Let us refine the elements of the behavior model for our example. First, the use of the
phrase "establish ground" must be clarified. On a tester, this means that the ground pins of the
UUT connect to the digital, analog, or system ground on the tester. Next, consider what it means
to "establish PS_1." This means that there is a stable voltage of the proper value at the proper
pins on the UUT. This can be brokent into two pieces: the declaration of a voltage at the UUT
pins and a constraint on the value of the voltage:
establish_PS_1:
signal Vcc1 DC_SIGNAL located at (HI=Ps1_Pin, LO=Gnd_Pin)
constrain Vcc1.voltage > 4.75V AND Vcc1.voltage < 5.25V
At this point, four of the five entities in the simplified behavior model are evident:
. There is a signal named Vcc1. The type of the signal is DC_SIGNAL, where
the type is an extension to the simplified model (as shown in Figure 2).
. There are two locations, named Ps1_Pin and Gnd_Pin, where the signal
Vcc1 occurs.
. There is a constraint that restricts the voltage attribute of Vcc1 to lie between
4.75V and 5.25V.
. There is a behavior named "establish_PS_1" that defines the period over
which the property definitions are active 2 .
This behavior model states that there is a voltage between two pins on the UUT and that the
voltage must lie within the range 4.75V to 5.25V. The behavior does not provide the actual value
for the voltage or even constrain the value to be constant for the duration of the behavior
(however, constancy is implied by the type, DC-SIGNAL).
Given this model, a test program can be verified to satisfy the objectives and constraints of
the model, thereby verifying that the test program is "behaving" as specified. Formally, the test
program itself cannot be verified. Rather, the test program can be run and the resulting execution
trace examined. From the execution trace, the voltage corresponding to signal Vcc1 can be
determined to ensure the voltage lies within the proper range for the duration of the
establish_PS_1 behavior.
Notice that no time entities are defined for the example. In a test program the behavior
establish_PS_1 begins at some time and later ends, but no specific values have been
assigned, nor should they be. For this example, the start and stop times are identified by
examining the execution trace of the program rather than being included in the test program to
prescribe specifically when the behavior occurs.
In considering the whole test program, however, one finds that the start and stop
times are specified, but in terms of timing constraints. For example,
whole_test_program:
behavior PS1 establish_PS_1
behavior PS2 establish_PS_2
behavior RT run_tests
constrain PS1.stop <= RT.start AND PS2.stop <= RT.start
In this example, the behavior defined by whole_test_program contains three sub-behaviors
(named PS1, PS2, and RT). Behavior whole_test_program also contains a constraint
that relates the start and stop times of the three sub-behaviors such that the ordering of the
behaviors conforms to the flow chart in Figure 3. Notice that the start and stop times, while
specified in the constraint, do not have values specified anywhere. As described above, the actual
values are derived from the execution trace of the test program.
APPLICATIONS OF BEHAVIOR
In the following sections, we will provide several examples using the constraint model.
These examples are, necessarily, simplified, but they serve to further illustrate the concepts
introduced in the previous section.
The behavior model can be applied during test requirements specification, synthesis, and
verification. A common thread through these applications is the use of the behavior model for test
program specification. Test resource allocation is a fourth application that can occur during test
2 In this example, no specific duration is specified.
program development (i.e., static allocation) or during test program execution (i.e., dynamic
allocation). Other applications are expected as the model becomes more widely used.
Test Requirements Specification
The behavior model can be used to capture test requirements. Test requirements, in this
context, are requirements on the test program itself, not requirements on the test development
process (Nagy & Newberg, 1994; Atkins & Rolince, 1994). The behavior model addresses test
requirements such as:
. A safe-to-turn-on test must be performed before any other test.
. Tests must be run over a range of ambient temperature.
. Frequency stability must be measured at 1.250000 Mhz.
Using these requirements as examples, we will demonstrate how to represent requirements in the
behavior model and how to use the requirements in test program synthesis and verification.
The above test requirements are provided in English and, although understandable to
engineers, are difficult for a computer to understand. The first step for specifying requirements in
a machine-understable way is to add detail to the above statements until they can be expressed
formally.
Safe-to-Turn-On Test Requirement
A safe-to-turn-on (STTO) test is defined as a behavior that precedes all other behaviors in
the test program. The test program itself represents an enclosing behavior that includes the STTO
test and all other tests. The STTO behavior typically tests for shorts between power and ground
with a direct resistance measurement and then tests for excessive current when the UUT is
powered. The STTO "returns" a value that determines whether any further tests may be run.
Specifically, the STTO behavior can be represented as
whole_test_program:
behavior ST safe_to_turn_on(safe_to_test boolean)
behavior RT run_tests
constrain IF RT.execute THEN RT.start >- ST.stop
constrain IF RT.execute THEN ST.safe_to_test
In this model, a behavior is defined as whole_test_program that contains two sub-
behaviors: ST and RT. Behavior ST is an instance of the safe_to_turn_on behavior (defined
above). ST has a return parameter called safe_to_test. Behavior RT simply encapsulates all
other tests in the test program.
3 In this example, we introduce the "RT.execute" notation. RT.execute is TRUE if the sub-behavior, RT,
actually executes and is FALSE otherwise. However, just because a sub-behavior is declared inside a behavior does
not mean that the sub-behavior actually executes. Additional constraints are required to ensure that the sub-behavior
executes as many or as few times as necessary.
The first constraint ensures that, if RT actually executes, then RT follows ST. The second
constraint ensures that RT can only execute if behavior ST returns TRUE for the safe_to_test
parameter. This constraint looks "backwards" because the behavior that is supposed to occur
(RT.execute) appears as the test to the IF statement, and the behavior that is supposed to
have occurred appears in the THEN clause of the IF. Behavior descriptions are declarative-they
do not prescribe how to execute a test program; they describe what must be true after the test
program executes.
After the test program executes, the execution trace will have a value for RT.execute
and ST.safe_to_test. The only way the constraint can be satisfied is if both
ST.safe_to_test and RT.execute are TRUE, or if RT.execute is FALSE. Notice that
RT is not required to actually run. Instead, the requirement is that RT not run unless the UUT
its safe-to-turn-on test.
Test Test Requirement
Products typically have a temperature range over which they are expected to operate. This
normally implies that the product must be tested at more than one ambient temperature. Let us
assume that our example product will be tested at three temperatures: room temperature, a low
temperature, and a high temperature. This assumption can be captured by first expanding the
definition of the run_tests behavior to include the notion of ambient temperature.
run_tests:
signal ambient temperature
Next the definition of whole_test_program is expanded to require that run_tests
execute at least once with the temperature around room temperature, once with the temperature
near the low end of the range, and once with the temperature near the high end of the range.
whole_test_program:
behavior ST safe_to_turn_on(safe_to_test boolean)
behavior RT_room: run_tests
constrain IF RT_room.execute THEN RT_room.start >= ST.stop
constrain IF RT_room.execute THEN ST.safe_to_test
constrain IF RT_room.execute THEN RT.ambient in room_range
behavior RT_low: run_tests
constrain IF RT_low.execute THEN RT_low.start >= ST.stop
constrain IF RT_low.execute THEN ST.safe_to_test
constrain IF RT_low.execute THEN RT.ambient in low_range
behavior run_tests
constrain IF RT_high.execute THEN RT_high.start >= ST.stop
constrain IF RT_high.execute THEN ST.safe_to_test
constrain IF RT_high.execute THEN RT.ambient in high_range
The whole_test_program description has been modified to include three copies of
run_tests, each of which is constrained to run within a particular temperature range (denoted
by names such as room_range, low_range, and high_range, that would be defined in a
full model). Note there are no sequencing constraints between the various run_tests; an
implementation is free to pick whatever temperature sequence it deems most appropriate.
Also notice that none of the run_tests are required to execute. In this particular
example, the decision about execution is left to the diagnostic controller. The diagnostic controller
might, for instance, decide not to test at high and low temperature if the room temperature test
fails. Such a decision is entirely consistent with the test requirements in the example.
Frequency Stability Test Requirement
A frequency stability test might verify that a UUT output signal has a constant frequency.
The term "constant" must be qualified to mean "constant within some error." This test
requirement can be captured by defining it in terms of a behavior. One approach to specifying the
behavior is:
frequency_stable:
signal Osc AC_SIGNAL located at (HI=Osc_Pin, LO=Gnd_Pin)
constrain abs (Osc.frequency - 1.25 MHz) < Freq_Error
This model defines a behavior, frequency_stable, with one signal that is of type
AC_SIGNAL. There is a single constraint that forces the frequency to be "close to" 1.25 Mhz,
where "close to" is defined as being within Freq_Error. Unfortunately, this description is
incorrect because one does not know if the oscillator is really stable, nor can it be forced to be
stable. The current description demands that the oscillator be stable and invalidates any
observation of behavior for which the oscillator is not stable.
The description needs to report whether or not the oscillator is stable rather than forcing
the stability of the oscillator. Once again, the focus is on describing rather than prescribing
behavior. For example,
frequency_stable:
property Osc_Ok boolean
signal Osc AC_SIGNAL located at (HI=Osc_Pin, LO=Gnd_Pin)
This description says that the Osc_Ok property is TRUE if the oscillator frequency is stable,
and FALSE otherwise. Notice that Osc_Ok is not required be TRUE. It will be TRUE for a fault-free
UUT and may be FALSE for a faulty UUT. The behavior frequency_stable is permitted
to take on either value, and it is reasonable to expect that diagnostics will use Osc_Ok (among
others) to indicate whether the UUT is faulty.
Test
Because it is declarative, a behavior description does not usually capture enough
information to directly generate code for a test program. However, a behavior can be used to
guide test program generation (Papachristou & Carletta, 1995). In general, the code synthesis
process can follow a constraint satisfaction process coupled with a code generator as a side effect
(Dechter, 1992; Pearl 1988). For example, in determining the order in which to execute RT and
ST, legal values (or ranges of values) need to be instantiated for the RT.start and ST.stop
variables. As a side effect of instantiating these values, a code generator can determine that
functions associated with RT and ST must be generated that are sequenced according to these
legal values.
For illustration, consider the example from the previous section describing the STTO test.
For this example, when synthesis begins, code implementing whole_test_program must be
generated. This might involve including standard startup code and may include the generation of
site-specific user interfaces. The test requirements in the behavior description are silent on such
issues, and the synthesis program is expected to generate such details from other sources of
information. The separation of test requirements that depend only on the UUT from information
about the test equipment or local test procedures is deliberate and is a principal advantage to
using the behavior model. The remaining discussion will assume that the synthesis program will be
adding local information, and will talk only in terms of satisfying the test requirements.
Having begun whole_test_program, one must select a component of the test
program to synthesize. There are four statements in whole_test_program, two behaviors
and two constraints. Note that the first constraint prohibits running RT before running
ST. Also note that the second constraint cannot be evaluated until ST executes. Therefore, ST
will be synthesized first, which is exactly what common sense would dictate.
Now a branch that executes RT only if ST returned TRUE for its safe_to_test
parameter will be synthesized. When using a programming language like C, the code for
whole_test_program would resemble the following skeleton:
void whole_test_program ( void ) {
boolean safe_to_test;
- Execute Safe_To_Turn_On,
- getting the safe_to_test parameter back.
safe_to_turn_on ( &safe_to_test );
Execute Run_Tests only if safe_to_test is true. -
safe_to_test ) {
Note that the constraint that ST run before RT is ensured by the order in which the
safe_to_turn_on and run_tests routines are called in the test program. Also note that
the C program executes run_tests if safe_to_test is TRUE, even though the test
requirements did not demand this. Test programs are often more constrained than the test
requirements due to considerations such as operator convenience, test time minimization, or other
concerns not directly related to the requirements.
Test
Test program verification is the process of comparing an existing test program with a set
of test requirements to ensure that the program satisfies the requirements (Caunegre & Abraham,
1995). As discussed earlier, the behavior description of the test program constrains its execution
trace, and only the execution trace truly can be verified. However it is both impractical and
inefficient to verify each execution trace; therefore, the alternative is to analyze the test program
itself and predict whether or not all execution traces that can be produced by the test program will
be correct.
Some aspects of an execution trace can be predicted with high confidence. Gross timing
relationships are a good example. In the following example, the behavior some_test has two
sub-behaviors (B1 and B2), and B2 must occur after B1.
some_test:
behavior B1 Test_A
behavior B2 Test_B
constraint B2.start > B1.stop
If the corresponding test program is written in a sequential programming language such as C, and
if B1 and B2 are implemented as subroutines, the code for some_test might look like:
some_test ( void ) {
In this case, B2 is guaranteed to follow B1 unless some catastrophic failure occurs in the compiler
or in the host computer.
Other aspects of an execution trace can be predicted with less certainty. For example,
consider a behavior that contains a signal whose voltage is constrained to a small range around
3.3V:
some_voltage_test:
signal Vcc DC_SIGNAL located at (HI=Ps1_Pin, LO=Gnd_Pin)
constrain abs(Vcc.voltage - 3.3V) < 0.1V
This behavior might be implemented by code that programs a power supply to 3.3V.
Analysis of the test program code would show that the power supply programming is consistent
with the behavior; however, the execution trace would be consistent with the behavior only if the
selected power supply had adequate accuracy and precision and if the line loss between the supply
and the UUT was negligible. These are concerns that test engineers deal with on a daily basis and
that must be considered during the analysis.
Sometimes analysis of the test program code does not yield enough information to
conclude anything about the expected execution trace (e.g., when interactions between the
selected test resource and the interface test adapter cannot be predicted easily). In these cases
simulation of the test program, also called "virtual tests," can generate predictions of execution
traces for the test program (Miegler & Wolz, 1996). These predicted execution traces can be
verified with respect to some behavior, and with enough such simulations, the test program could
be declared to be acceptable.
Test Resource Allocation
Test resource allocation identifies candidate resources and then determines if the
candidates are suitable for the required task (Hardenburg & Nichols, 1995). Test resource
allocation is an important function in test development, and automation of this function is
important when automating the test program generation process. Automated allocation also
enables dynamic allocation of test resources, that in turn leads to more portable test programs. A
test program will have one or more requirements that must be satisfied by a test resource, and a
test resource will have a set of capabilities. If the resource capabilities satisfy the requirements
then the resource is functionally suitable.
The behavior model supports the test for functional suitability by acting as a specification
for both the test requirements and the test resource capabilities. For example, supposed the
following test requirement is applied to an amplifier with a gain of two.
some_test:
signal V1 DC_SIGNAL
signal Vin DC_SIGNAL located at (HI=In_Pin, LO=Gnd_Pin)
signal Vout DC_SIGNAL located at (HI=Out_Pin, LO=Gnd_Pin)
signal V2 DC_SIGNAL
property Amp_Ok boolean
constrain abs(V1.voltage - 4V) < 0.5V
constrain abs(Vin.voltage - V1.voltage) < 2mV
constrain abs(V2.voltage - Vout.voltage) < 2mV
There are four signals in this behavior:
1. V1 is the input voltage to the amplifier program, as programmed
2. V2 is the output voltage, as reported by some instrument
3. Vin is the actual input voltage to the amplifier
4. Vout is the actual output voltage of the amplifier
There are also four constraints in this behavior.
1. The programmed input voltage can be any value in the range 3.5V to 4.5V.
2. The actual input voltage must be within 2mV of the programmed voltage.
3. The reported output voltage must be within 2mV of the actual output voltage.
4. The boolean property Amp_Ok is true if the amplifier gain, calculated with the
programmed and reported voltages, is two, plus or minus one tenth of one percent.
From this description, three things about some_test can be observed. First, the use of
signals for the programmed and reported voltages allows the behavior model to capture
accuracy requirements. The relationship between Vin and V1 is one accuracy constraint, and the
relationship between V2 and Vout is the other. Second, while the behavior model allows the test
program to test the amplifier at any voltage in a one volt range (e.g., 3.5V to 4.5V), the accuracy
of the overall test is required to be relatively high. This requirements cannot be specified with a
simple range on Vin. Third, there is an implicit constraint between Vin and Vout since Vin is
constrained relative to V1, Vout is constrained relative to V2, and an explicit constraint exists
between V1 and V2. This constraint is similar in form to that between V1 and V2 and might be
classified as a product requirement.
A test resource is required to implement the behavior specified by this model. To obtain
the required behavior, two resources will probably be required-one to apply the input voltage
and one to measure the output voltage. For the sake of discussion, consider only the measurement
resource. The input resource would be treated similarly. A possible behavior model describing the
measurement resource is:
property Offset Voltage
property Tolerance Real
signal Vmeas DC_SIGNAL located at (HI=Input_Pin, LO=Gnd_Pin)
signal Vread DC_SIGNAL
constrain -10V <= Vmeas AND Vmeas <= 10V
constrain abs(Vmeas - Vread) < (Offset
constrain 0V <= Offset AND Offset <= 100uV
Tolerance AND Tolerance <= 2e-4
This resource has two signals-the voltage that appears at the input and the voltage as
reported by the resource. The behavior has four constraints. The first limits the range of the input
voltage to plus or minus 10V. The last three constraints limit the measurement error. The first
expresses the resource accuracy as a linear function of Offset and Tolerance, the second
limits the legal range of Offset, and the third limits the legal range of Tolerance. Notice that
the behavior does not state that the Offset, for example, is 100uV. Instead, the behavior states
that the Offset is no more than 100uV.
When interpreting this model, the measure_spec behavior states the behavior of the
resource. It gives no information about how to control the resource. One approach for controlling
the resource is for the resource to have a separate set of methods that provide program control. If
this was the approach taken, one would expect to find a method that returns Vread.voltage,
but no methods for returning Vmeas.voltage, Offset, or Tolerance. Further, there
would be no methods for setting any of the properties or signals. This set of methods is
entirely consistent with the control of real resources.
Assume that some process has chosen the resource associated with measure_spec to
implement some of the test requirements in some_test. If the resource is connected to the
UUT, a new behavior will be specified that is the union of the original behaviors:
some_test_using_resource:
behavior X some_test
behavior Y measure_spec
constrain abs(X.Vout.voltage - Y.Vmeas.voltage) < ITA_Loss
There is an instance of some_test and an instance of measure_spec. The sub-behaviors X
and Y should be constrained to be simultaneous, but those constraints have been omitted for
simplicity. There is an additional constraint that couples the UUT output voltage with the test
resource input voltage, corresponding to wiring in the interface test adapter. The constraint does
not say that the two voltages are equal. Rather, it states that the two voltages are closer than
some factor called ITA_Loss.
If the test resource is compatible with the test requirements, there will be no conflicts in
the constraints. The constraints (numbered for convenience) that are coupled by connecting the
resource with the UUT are:
signal V1 DC_SIGNAL
signal Vin DC_SIGNAL located at (HI=In_Pin, LO=Gnd_Pin)
signal Vout DC_Signal located at (HI=Out_Pin, LO=Gnd_Pin)
signal V2 DC_SIGNAL
property Amp_Ok boolean
1. constrain abs(V1.voltage - 4V) < 0.5V
2. constrain abs(Vin.voltage - V1.voltage) < 2mV
3. constrain abs(V2.voltage - Vout.voltage) < 2mV
4. constrain
property Offset Voltage
property Tolerance Real
signal Vmeas DC_SIGNAL located at (HI=Input_Pin, LO=Gnd_Pin)
signal Vread DC_SIGNAL
5. constrain -10V <= Vmeas AND Vmeas <= 10V
6. constrain abs(Vmeas - Vread) < (Offset
7. constrain 0V <= Offset AND Offset <= 100uV
8. constrain 0 <= Tolerance AND Tolerance <= 2e-4
9. constrain abs(Vout.voltage - Vmeas.voltage) < ITA_Loss
If the UUT is good, one can deduce from the model that the output voltage may range
from approximately 7V to 8V (the output may actually range from 6.992502V to 9.008502V as
derived from constraints 1, 2, and 4). This lies comfortably within the resource input range given
by constraint 5. Note that the range of Vout was not constrained; therefore, one cannot be
certain that Vmeas will lie within the 10V range. In the present example, one could probably
clamp Vout to protect the resource input without affecting the validity of the test program.
If the UUT is good, one can also deduce from the model that Vread is an adequate
substitute for V2, provided the ITA_Loss is less than 100uV. The maximum error of the
resource (given by Vread with respect to Vmeas) occurs at 9V and is 1.9mV, as specified by
constraints 6, 7, and 8. The maximum error permitted on V2 (given by V2 with respect to Vout)
is 2mV, as specified by constraint 3. The maximum error between Vout and Vmeas is
ITA_Loss, as specified by constraint 9. Therefore, if ITA_Loss is no more than 100uV,
Vread from the resource can be substituted for V2 in constraint 4.
This example illustrates that analyzing the behavior specifications of the test requirements
and the resource capabilities "verifies" that the resource satisfies the requirements and can be used
in the test program (provided the ITA loss is kept low enough). Different values in any of the
constraints could lead to a different conclusion.
Triggers and Events
One reasonable issue for the behavior model to address is the representation of events,
including various triggers and timers. The behavior model quite readily represents these concepts
but does not recognize them in any special way. A trigger defines a precise timing relationship
between two actions. For example, a trigger can establish a relationship between the rising edge
on a voltage signal and the start of an oscillator. This is shown in Figure 4.
The behavior model captures the trigger as follows. Assume several sub-behaviors for
oscillator_on, oscillator_off, DC_low, and DC_high have been defined.
oscillator_trigger:
behavior Osc_Off oscillator_off
behavior Osc_On oscillator_on
constrain Osc_Off.start == Oscillator_Trigger.start
constrain Osc_On.start == Osc_Off.stop
constrain Osc_On.stop == Oscillator_Trigger.stop
behavior Trig_Down DC_low
behavior Trig_Up DC_high
constrain Trig_Down.start == Oscillator_Trigger.start

Figure

5. Pairing Two Oscillators
oscillator
voltage
delay

Figure

4. Trigger Initiating Oscillator
constrain Trig_Up.start == Trig_Down.stop
constrain Trig_Up.stop > Trig_Up.start Trig_Delay
constrain Osc_On.start == Trig_Up.start Trig_Delay
There are four sub-behaviors of oscillator_trigger. Two govern the behavior of an
oscillator and must occur sequentially (i.e., Osc_On starts as soon as Osc_Off stops).
Together, these two sub-behaviors span the entire containing behavior. Two sub-behaviors
govern the trigger signal itself. These two sub-behaviors are also sequential, but they need not run
to the end of the containing behavior. In this example, once the oscillator is running, the trigger
signal can change without affecting the oscillator. Finally, a constraint is imposed on the oscillator
to turn on after some delay following the rising edge of the trigger signal. This delay is named
Trig_Delay in the example and would normally be passed as a parameter to the behavior.
Notice that oscillator_trigger describes a simple timing relationship, but there is
no indication of how the relationship is to be implemented. It could be implemented through a
trigger, through software, or as a side-effect of something else in the test program. The behavior
model only describes the constraints and not how to satisfy the constraints.
In the real world, equality constraints are difficult to realize. For example,
oscillator_trigger requires that the time difference between Trig_Up.start and
Osc_On.start be exactly Trig_Delay. The time difference would never be exactly
Trig_Delay in a real test program, nor does it matter. Instead, the actual time difference (as
measured in the execution trace) should be Trig_Delay, within some error. This is captured in
the following constraint:
constrain abs((Osc_On.start - Trig_Up.start) - Trig_Delay)
< Trig_Error
The new constraint says that the difference between the actual delay (Osc_On.start -
Trig_Up.start) and the desired delay (Trig_Delay) must be less than some allowable
error (Trig_Error). More complicated constraints can be used to capture asymmetric
tolerances (i.e., tolerances not symmetrically distributed about the expected value).
Returning to the example, it is evident the behavior model adequately describes the
relationships implemented by events and triggers. It is also evident that the behavior model does
not distinguish between timing relationships that are implemented in hardware (e.g., triggers) or
software (e.g., software delay loops). The primary difference between hardware triggers and
software timing is in the potential error in the triggering delay. A test programmer selects a
voltage
delay
delay

Figure

6. Implementing Two Paired Oscillators.
hardware implementation to get a precise delay but is then concerned with issues of accessing,
allocating, and controlling the hardware to obtain the desired delay. On the other hand, the test
programmer selects a software implementation when precision is less important than ease of
programming.
A test program would not normally use a behavior such as oscillator_trigger.
The trigger signal in the example is probably an implementation detail. A more likely scenario is a
behavior in which two oscillators start within a fixed time of each other. This can be illustrated as
in

Figure

5 and might be implemented as in Figure 6. The behavior should properly describe the
requirement that the oscillators begin at the same time and not the implementation detail of
referencing both to a common rising edge.


In this paper, we provide a description of the behavior information model proposed for the
next generation test system architecture under development by the ARI. This model facilitates the
specification of behaviors related to test subjects, test requirements, test strategies, test resources,
and product diagnostics using a declarative approach. As such, the behavior model provides a
formal approach to specifying behaviors, thereby facilitating the specification and development of
reusable and transportable test programs.



--R

Abstract Interpretation of Declarative Languages
"TRSL Standard Supports Current and Future Test Processes,"
"Achieving Simulation-Based Test Program Verification and Fault Simulation Capabilities for Mixed-Signal Systems"
"Formal Methods-Mathematics, Theory, Recipes or What?"
"Constraint Networks: A Survey,"
"Seven Myths of Formal Methods,"
"The IEEE ABBET Lower Layers Definition and Status,"
Introduction to Logic Programming

"Development of Test Programs in a Virtual Test Environment"
"Capturing Board-Level Test Requirements in Generic Formats,"
"Test Synthesis in the Behavioral Domain,"
Probabilistic Reasoning in Intelligent Systems
Information Modeling: The EXPRESS Way
"The Industrial Use of Formal Methods,"
--TR
automatic test systems;test programming;test requirements;behavior modeling