Process Model Theory

Testing a UUT requires more than just executing a set of tests. Usually, the test system must perform a series of operations before and after it executes the sequence that performs the tests. Common operations include identifying the UUT, notifying the operator of pass/fail status, logging results, and generating a test report. These operations, which define the testing process, and their flow of execution is comprise a process model. The process model is one feature of TestStand that sets it apart from both commercial and home-grown monolithic test executives.

Without a process model, each test sequence would need to provide the mechanism for these common tasks. This code would have to be repeated in each new test sequence created. Any changes to the operation of these common tasks would need to be repeated in each test sequence. Using a process model, you have increased modularity and reusability by keeping all of the code that performs common tasks. Any modifications to the common operations need to be changed in only one common location.

There are several advantages to the process model architecture used by TestStand. You can use a single process model with several different test sequences, which minimizes development effort and improves maintainability in the future. An additional advantage is that you can run a single test sequence within several process models, which results in increased flexibility when running in different environments. The same test sequence can be used for validation and verification tasks during development and be passed onto the factory floor to test UUTs in a different process model. Thus the test process can change but the tests executed remain the same.

TestStand is shipped with three default process models that you can modify or replace – the sequential model, the batch model, and the parallel model. You can use the sequential model to run a test sequence on one UUT at a time. Using the parallel and batch models, you can run the same test sequence on multiple UUTs at the same time. Each process model gives a different test experience without requiring any modifications to the client sequence file.

Figure 1: The parallel process is very useful for independent test fixtures.

Figure 2: The batch process model can be used to test many units that reside in the same test fixture.

Monolithic test executives often implement their process model internally and do not allow you to modify them. TestStand provides a mechanism for defining your own process model or customizing an existing one. Process models are represented as a sequence file that contains three special types of sequences with which users can customize behavior. You can edit a process model in the same way that you edit your sequence files to create customized behavior. By representing a process model as a sequence, it becomes simple to edit and extremely flexible. Changes can be made in any language and any arbitrary code can be added. You can modify the process model by opening it in the sequence editor and adding steps the same way one creates client sequence files.

One type of special sequence in a process model is a model callback. Model callbacks are sequences that are typically executed inside of a process model, but client sequences can override the default behavior. When a callback is overridden, rather than calling the code inside of the process model sequence, code is executed in the client sequence. With this feature you can implement unique behavior for a particular test sequence without impacting other parts of the process model. For example, for one particular type of UUT, you may want to use a bar code scanner rather than the manual serial number entry. Other examples of a model callback are the process setup and process cleanup sequences. When testing a large batch of UUTs, it may make sense to initialize and clean up a set of instruments a single time rather than initializing and cleaning up before and after every UUT. Overriding the process setup and process cleanup callbacks in a client sequence is an effective way to add functionality to the testing process without impacting other common tasks in the process model. Callbacks increase modularity of code but allow maximum flexibility for customized behavior.

Figure 3: With callbacks you can override the behavior of the process model by implementing sequences in a client sequence.

Another special type of sequence in a process model is an execution entry point. Execution entry points in a process model offer different modes of execution that lead to different testing procedures. The TestStand default process models have two entry points – test UUTs and single pass. The test UUTs execution entry point executes in a loop that repeatedly identifies and tests UUTs. The single pass execution entry point tests a single UUT without identifying it. Execution entry points can be configured for restricted user access. For example, operators can run only the test UUTs execution entry point, but technicians can run both the test UUTs and single pass execution entry points. With TestStand, users can customize the process model to create their own entry points for other purposes, such as debugging. The TestStand Sequence Editor automatically will populate additional entry points to the appropriate menu. Operator interfaces can accommodate the addition of execution entry points without changing a single line of code. This modular architecture creates incredible flexibility and maintainability by reducing the amount of recoding when changes are made to the process model.

The final special type of sequence in a process model is the configuration entry point. With configuration entry points, an operator can set various configuration options for the process model, such as configure report options and configure database options. Like the other parts of the process model, configuration entry points are fully customizable. Existing entry points can be customized for additional options and new configuration entry points can be added to add different options. Using configuration entry points, a station can be configured in several different ways without changing code. For example, one test station can be used to diagnose problems and may not need to use database logging. By using the configure database options configuration entry point, this station can be configured to disable database logging without the need for recoding the process model. Similar to the execution entry points, configuration entry points are automatically added as menu items when they are created. No code needs to be rewritten in operator interfaces to add these options.

By using the process model and all of its features, you can create an extremely powerful, flexible test application with minimal effort. The TestStand implementation of the process model simplifies development by using a modular architecture that minimizes the amount of code changes that need to be made to affect every part of a test system. Using the TestStand process model architecture will result in a tremendous savings in time and money when developing a complete test system, both in development and maintenance costs.