NIST project researches testability of PDMs

The rapid evolution of integration technologies that allow software applications to be constructed from standalone system components or commercial off-the-shelf (COTS) packages has changed the way that software systems for manufacturing and other domains are built. The initial wave of integratable components was made available as software libraries with interfaces in a wide variety of programming languages. More recent advances such as the Common Object Request Broker Architecture (CORBA) and the Component Object Model (COM) have made the integration task even easier by allowing a component to be developed once and automatically made available to multiple programming languages.

Components that were originally deployed in different places and times are now being wrapped with standard interfaces and made to interact with one another. This practice has created a new category of problems for software testers, who must not only find component faults, but also integration faults such as unintended interactions between components and misunderstood interface semantics.

The Testability of Interaction-Driven Manufacturing Systems (TIMS) project in Manufacturing Engineering Laboratory of the National Institute of Standards and Technology is seeking to develop a capability for testing in this new environment and to collect requirements for testability that can be designed into future specifications. Product Data Management (PDM) is now a focus for standardization in the manufacturing domain and promises to present some of the most important challenges in testing and testability in years to come. For this reason it is a primary target for TIMS attempts to "learn by doing" by developing test methods and extracting the requirements for testability.

The work focuses on two significantly different, yet conceptually related PDM standards: version 1.1 of the Object Management Group's (OMG) PDM Enablers standard, and the PDM Schema that is being developed for the ISO Standard for the Exchange of Product Model Data (STEP). These are both specifications for application interfaces to PDM systems, but they are from different sources and designed for different purposes. The goal is to find methods that exploit the conceptual commonality, yet remain adaptable to the very different environments in which the two specifications are defined.

A technical report detailing the following results will be available on the TIMS website in the near future:

• A unified testing approach that integrates the world views of the two specifications
• Three prototype conformance tests for PDM Enablers
• Testability issues reported to OMG
• Experimental software related to the test effort, including an EXPRESS-X mapping from the PDM Schema to PDM Enablers

Additionally, the following materials are available from OMG:

• PdmProductStructure-Definition test output
• Presentation to the Manu-facturing Domain Task Force at the Philadelphia meeting
• Test source code and output (March 1999)

Work on testing of the PDM Schema over the Standard Data Access Interface (SDAI) is ongoing. SDAI is a part of STEP; it defines the interface by which a program may access data described by an Express schema "online" (as opposed to using exchange files). SDAI is schema-independent, so the combination of PDM Schema and SDAI yields a scope analogous to that of the PDM Enablers standard.

Given the strong emphasis placed on semantic clarity by STEP, one would expect that many testability problems would be avoided. However, STEP does not yet include the definition of transactional units suitable for an interaction-driven system. Abstract test cases for STEP generally emphasize data ex-change, where the data is viewed as a static unit. Contrariwise, SDAI provides a very "fine-grained" interface for dealing with STEP data, in which many operations must be performed in some particular order to accomplish what would be considered a complete unit of work. To build meaningful test cases using SDAI, it is necessary to collect SDAI operations into "coarse-grained" transactions that have meaning within a testing scenario. But testers lack a normative STEP reference to validate the transactions that they design (e.g., to establish that the ordering of operations is legal). Thus, it is difficult to create an SDAI test client that arguably should execute correctly on any conforming implementation.

The TIMS project is experimenting with using test scenarios defined via a PDM Enablers interface as the basis for SDAI test cases. The test system prototype is using two implementations of the SDAI C language binding. The system will compare the results of running the test cases against both systems. The test result will provide an indication of the compatibility of the two systems rather than a definitive evaluation of one over the other. Not only will these results provide useful input to the developers of these systems but they will also be a basis for establishing an SDAI testing process. For a discussion of some of the issues in SDAI testing see the paper "Testability of Product Data Management Interfaces". The SDAI testing prototype will be completed in the next few months. A by-product of the work is a mapping of the PDM Schema into a form compatible with the PDM Enablers. The mapping is documented using EXPRESS-X and is available to interested parties.

For more information, please refer to the TIMS project home page http://www.mel.nist.gov/msid/tims

Note:
Commercial equipment and materials are identified in order to describe certain procedures. In no case does such identification imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.