Browse Prior Art Database

Architecture for a Test Control System in Os/2

IP.com Disclosure Number: IPCOM000119284D
Original Publication Date: 1991-Jan-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 3 page(s) / 104K

Publishing Venue

IBM

Related People

Clark, RA: AUTHOR

Abstract

A Test Control System (henceforth referred to as TCS) provides software support to control a collection of hardware and software functions primarily for the purpose of manufacturing product test and verification. Typically, these systems run from a Personal Computer.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 48% of the total text.

Architecture for a Test Control System in Os/2

      A Test Control System (henceforth referred to as TCS)
provides software support to control a collection of hardware and
software functions primarily for the purpose of manufacturing product
test and verification. Typically, these systems run from a Personal
Computer.

      This article outlines a successfully implemented TCS
architecture that offers a low-cost, modular solution in OS/2* using
Presentation Manager* user interface.

      OVERALL SYSTEM ARCHITECTURE The system is architected into four
main levels.  Each level, described below, is also broken into
several modular blocks, packaged in OS/2 Dynamic Link Libraries
(DLLs).
System              This level contains system code common
                to all testers to provide consistent user
                interface and configurability.
Shell               This level contains tester-dependent
                system code which understands how the
                application test data is partitioned and
                executed.
Application              The actual test code and data to test a
specific PN resides at this level.
Instrument               Access to all tester hardware
                occurs at the instrument level. Separate
                blocks exist for each type of hardware to be
                supported.

      INSTRUMENT SUPPORT To maximize both programming and user
interface consistency, a three-layer design is used which groups
instruments in classes of similar function. Each level is comprised
of one or more DLL blocks installed as needed by the system.
Logical             This driver provides a single 'logical'
                interface for a class of instruments by
                isolating application and system software
                from specific hardware. It also provides
                multi-thread and multi-process support as it
                routes calls to the appropriate lower level
                driver.
Command             This driver actually processes function
                calls in a manner specific to a particular
                instrument.  The intention is that multiple
                command drivers can be associated with a
                common logical driver although this is not
                enforced in the design.
Physical            This driver handles the communications
                medium, such as GPIB, to the actual
                instrument hardware and is normally vendor
                supplied.

      TEST PROGRAM STRUCTURE From a...