Testengineers

ATMLA New Standard for ATE

The next-generation ATML data exchange standards for ATE and test information sharing cannot arrive soon enough.

For many years, leading electronics manufacturers have searched for standards to improve-the way they share test-system and test-result information with the rest of the enterprise. Despite initial industry efforts to regulate test-system and execution communications through standards such as IPC 25xx, many test organizations already have or are considering developing their own proprietary XML-based data exchange standards to meet specific needs for sharing ATE and test information.

However, this no longer may be necessary. A new XML-based standard for ATE and test information data exchange, known as Automated Test Markup Language (ATML), is emerging with widespread support among test and measurement industry leaders as well as major government programs.

Led by the Naval Air Systems Command and ATE industry members, ATML is a cooperative effort to define a collection of XML schemas to represent test information such as test programs, test asset interoperability, and unit-under-test (UUT) data including test results and diagnostics procedures. While the military and aerospace (mil/aero) community currently is driving the ATML specifications, other industries, including telecommunications, automotive, and consumer electronics, are likely to adopt these robust and flexible ATML schemas.

Data Exchange Among Systems
Imagine the following scenario to appreciate the potential a standardized data exchange process holds within your organization:

XYZ Medical, a medical device manufacturer, currently is working on the release of its latest EKG/ECG machine. During a manufacturing test run, one unit fails functional test since one of the acquisition channels appears dead. An operator quickly pulls this unit from the line and queues it at the diagnostics station where it undergoes a comprehensive set of functional tests, a superset of the manufacturing test.

During diagnostics, the operator identifies the fault within a supplier's analog acquisition subassembly. XYZ Medical returns the subassembly to its manufacturer, which issues the part to its diagnostics and repair group.

After performing another set of exhaustive diagnostics on the subassembly (since the OEM did not transmit prior failure information to the supplier), the supplier's repair technician determines that the field programmable gate array (FPGA) controling the acquisition logic has a short between two pins: the ground and an acquisition channel enable. Through experience, the repair technician knows that this particular FPGA short is responsible for 90% of the acquisition failures with the board but continues to run the full test suite. The technician then replaces the chip and returns the damaged one to the FPGA manufacturer for complete lot verification and statistical and fault analyses.

This example illustrates the typical but inefficient data exchange between manufacturers and, in many cases, even within divisions of the same manufacturer. The first data exchange breakdown occurs between the medical manufacturer functional test and diagnostic stations.

Had the diagnostics tests accounted for the functional test results, a more focused set of diagnostics on just the subassembly could have been performed, saving time. Also, if the medical manufacturer could have had access to the subassembly manufacturer's test plans, sequences, and modules, it could have leveraged its supplier's development efforts and significantly cut development time.

Similarly, had the subassembly manufacturer had access to the medical manufacturer's diagnostic results, it could have greatly streamlined the unit diagnostics and repair. Finally, if the manufacturer had previously captured statistical data on such failures, it could have shortened the test time and simply checked the FPGA for the common short that produces 90% of subassembly acquisition channel failures.

Lack of Standardized Data Exchange Driving Up Costs
The lack of standardized ATE and test information data exchange among companies and their suppliers and OEMs contributes significant overhead costs to manufactured products. This is especially prevalent in the mil/aero industry where typical units costing millions of dollars consist of hundreds of subsystems and involve dozens of mil/aero contractors and suppliers. For these reasons, incorporating the next-generation ATML data exchange standards for ATE and test information sharing cannot arrive soon enough for some organizations.

Inside the ATML
The ATML working group has been holding quarterly meetings for more than two years to work toward establishing an IEEE standard that provides increased industry and mil/aero ATE system compatibility and modularity. The group focuses on establishing a standard that provides and manages extensibility while supplying an exchange format that both humans and machines easily can interpret.1

In addition, the ATML standard is designed to improve several areas of ATE and test-system design by:

Implementing dynamic test sequences that adapt to historical data. Supporting instruments and their interface setups.

Capturing test information at various test stages.

These elements are crucial for subsystem data exchange and interoperation in large mil/aero applications involving multiple contractors. This information consists of test results, program information and sequencing, instrument and test-station specifications and capabilities, UUT specifications and requirements, and UUT diagnostics and maintenance information. The ATML effort also improves interchangeability among vendor tools and instruments, facilitates new technologies, and supports legacy test systems.

To facilitate data exchange between system interfaces, stations, and manufacturers and to ensure asset interoperability, the ATML working group has designated several external interfaces on which to standardize, including test-result reporting, diagnostics, test description, instrument description, test configuration, UUT data, and the test station. Drawing upon these interfaces, it has defined nine ATML components for an XML data interface:

Common TestResults Diagnostics TestDescription Instrument TestConfiguration UUTData TestStation

InterfaceAdaptor

While not all of the schemas are final, it is beneficial to look closely at the overall ATML structure and one of the approved schemas.

XML-Based ATML Structure
The ATML data exchange file is in ASCII text format with system-interface-specific tags or elements organizing the data. This ATML schema defines the specific elements and their hierarchy within this data exchange file. Because the text document is a file containing descriptive tags, it can operate on any platform, and a computer program can easily interpret and parse the tags based on the schema. For those same reasons, humans also can read it.

Basic ATML file structure begins with an XML header. The header describes the XML version and text character encoding. For example:

The root element follows the header and serves as the parent element for all other schema elements. In an ATML document, a name similar to the owning schema, such as or , commonly is the name of the root element. Nested within the root element are any number of child elements that can nest other elements according to the ATML component schema, which is the template file for standardizing the particular XML interfaces.

Because ATML uses the XML standard for describing ATE and test data, it takes advantage of recursion and extensibility, key technical benefits that give test systems greater flexibility in defining interfaces. By supporting recursion, element definitions describing test properties or tests can nest to create a more managed data-exchange format.

In XML, test-information extensibility adds data elements without disrupting current system operation. The ATML standard also includes general-purpose elements, such as OtherData and Extension, which can store additional information not specifically outlined in the ATML schema. All ATML-compatible systems can handle these miscellaneous elements differently or not at all and still operate correctly. As a result, ATML-based applications provide inherit flexibility and extensibility to maintain compatibility among systems.

TestResults Schema
To further gain insight into an ATML component, here is a look at the ATML TestResults component, which describes how test results should be organized.

As ATML defines, a test is any procedure for evaluating or quantifying the operation of a device or system. The TestResults schema provides a standard format for exchanging and storing measured values, pass/fail results, and accompanying data including test operator, station information, and environmental conditions.

The schema organizes this data in the form of XML elements. TestResults is the schema root element. The main result-collecting element for each ATML TestResults schema is the ResultSet element, which requires the ID attribute to properly identify the element. This element contains multiple TestGroup and Test elements.

The other elements included in the TestResults schema are the following:

TestResults (the root element) UUT ResultSet TestStation TestProgram TestDescription WorkOrder PreTestRepairs Environmental References Operator Indictments

Extension

TestResults Example
The following example demonstrates the TestResults reporting by using National Instruments• TestStand, a test-management environment for organizing, controlling, and executing automated test systems. There are three steps to ATML reporting behind the scenes of a NI TestStand sequence execution.

The first is the result collection by the TestStand engine into the TestStand ResultList container. The system tracks and stores all test properties, characteristics, and values in the ResultList container. The second step generates a TestResults schema-based XML report using the data in the ResultList container. The third step is the application of an ATML-compliant TestResults stylesheet that formats and displays TestResults XML data in a user-friendly HTML format.

Figure 1. TestStand ATML Test Report Stylesheet

To further illustrate the TestResults schema, the ATML TestResults report in Figure 1 is generated from the TestStand example test sequence in Figure 2. This sequence is a simple computer motherboard test on ROM, RAM, video, and keyboard components as well as the CPU and power subsystem.

Upon executing the example test sequence, TestStand automatically collects each test-step result and generates an ATML TestResults-compliant test report that it stores as an *.xml file. In Figure 1, the report includes the test station, operator, and sequence execution result. Each sequence call in TestStand is organized as a TestGroup element with individual test results nested within.

Figure 2. TestStand Test Sequence

The TestGroup element has an outcome value, and each nested test reports the outcome, date and time, test result, value, and specific test limits. Storing the test report in this format means other systems can easily interpret the test result data and share information because the pertinent data is organized in a standard hierarchy within known tags defining elements.

Additional ATML Components
In addition to the TestResults component which defines the result reporting system interface, eight other components comprise the ATML standard.1 These components cover the most common test-system and ATE interfaces:

Common
The ATML Common schema defines common types and attribute groups among the other eight schemas or their subschemas. This schema simply is a toolbox for the other schemas.

Diagnostics
The Diagnostics schema facilitates diagnostic information sharing among systems that collaboratively execute or analyze diagnostic procedures.

TestDescription
The ATML TestDescription schema outlines all the common interfaces for describing and executing a test program on a particular UUT. This includes test definition, group, and sequence as well as the underlying result evaluation procedures including test properties such as test limits. The goal of the TestDescription schema is to provide open-architecture standards for advanced test-program generation, test-program execution, and diagnostic reasoning applications.

Instrument
The ATML Instrument schema shares information describing an instrument interface definition within the tester and primarily is charged with commonly defining the instrument capabilities to facilitate instrument selection and validation during tester/test verification.

TestConfiguration
The ATML TestConfiguration schema identifies all of the hardware, software, and documentation necessary to test a UUT on a particular system.

UUTData
The UUTData schema defines and describes a UUT with information such as the part number, serial number, and operation requirements, and may include the unit operations history. This schema should completely document a particular UUT.

TestStation
The ATML TestStation schema facilitates a particular test-station specification and provides the framework to completely document a particular system, including system drivers, instrument interfaces and instruments, and system component calibration, and could contain the instrument instance descriptions.

InterfaceAdapter
The ATML InterfaceAdapter schema describes the paths between system ports and the UUT pins. This schema includes a framework for documenting the cables, connectors, wires, contacts, and everything needed to completely define mass interconnects including the receiver, cable assemblies, prewired adapters, contacts, and enclosures. This schema also contains manufacturer, model, and interfacing component capability information.

The ATML Reality
Many industries have adopted XML as a data exchange format, evident by the software vendors and hardware manufacturers that have incorporated XML features into their products and test systems. With the emerging promise of ATML as a test and measurement industry XML standard, some leading vendors already have begun implementing ATML capabilities into their products and test solutions.

For example, TestStand 3.1 from NI features a built-in example for compiling test reports according to the draft ATML TestResults schema. As the ATML schemas finalize, additional schema examples are planned for coming versions of TestStand.

BAE Systems is adapting its TPS Wizard to support the TestDescription ATML schema for generating TestStand sequences and NI LabWindows/CVI code snippets.2 Indra Sistemas incorporates capabilities to process and generate ATML TestResults-based reports in its ATE systems (SAMe). The SAMe product is the ATE concept the Spanish Ministry of Defense uses to support its weapon systems. Other organizations such as Lockheed Martin2 and Boeing3 also have been successful in prototyping ATML data exchange with the initial standard drafts.

Perfecting a Standardized Data-Exchange Interface
XML has proven to be an enduring technology for data exchange. There are industry-wide global benefits in using XML as a basis for ATE and test-information exchange standardization.

The new XML-based ATML schemas in next-generation automated test systems will impact the way test engineers approach defining and implementing test systems because they can use existing developments and systems without encountering inter-facing challenges. Ultimately, a stand-ardized approach to data-exchange interfacing means that test engineers can refocus their time and energy to the main task at hand developing test systems.

What Is XML?
Extensible Markup Language (XML) is a human-readable and machine-interpretable way to represent data for data exchange or storage. Built on the standard ASCII text format, it consists of user-defined tags to identify data (A in Figure 3). Because it simply is a method of formatting data in a text file, XML does not really do anything on its own. For it to be useful, a computer program must interpret or parse it.

How Is XML Different From HTML?
HTML displays data as a Web page, and XML is used for defining data for exchange. HTML has a predefined, specific tag set that Web browsers interpret to correctly display data on a computer screen. XML uses user-defined tags to identify a piece of data but not necessarily how to display it. Software interprets these user-defined tags as database fields or data descriptors.

How Do You Build an XML Data File?
Elements are the main XML file building blocks. Elements can be loosely or specifically organized according to a schema or template and have attributes and namespaces associated with them. Here are the main building blocks in XML:

Elements
An element, the basis for data organization, essentially is a data tag or descriptor. An XML document has only one root element that acts as a parent element to any embedded subelements. Each embedded subelement at the same hierarchal level is called a sibling while the containing element is the parent. From the opposite perspective, each parent element can have children subelements (A in Figure 3).

Schema
A schema is a template file that describes which elements are found in a given XML file and how they are organized. With a schema, XML is organized to provide a common data interface between different XML systems.

Attribute
An attribute is a piece of data that usually describes an element (B in Figure 3).

Namespace
A namespace differentiates two elements of the same name. A namespace always is associated with an element and is the prefix to the element name (C in Figure 3).

Figure 3. An XML Data File

References
1. IEEE,  Automatic Test Markup Language,• December 2004, http://grouper.ieee.org/groups/scc20/tii/ATML/Working Groups/Management/ATML Overview.doc
2. O Donnell, S.J. and Richardson, P.,  Implementing ATML Into an Existing Software Architecture,• AUTOTESTCON 2004 Proceedings.
3. Wegener, S.A.,  Practical Implementation of an Open Test System Using ATML,•  AUTOTESTCON 2004 Proceedings.

About the Author
Ron Harrison is the product marketing manager for Automated Test Software at National Instruments. Other positions held at NI include project manager within the Web Support Organization and application engineer. Mr. Harrison received a BASc. in computer engineering from the University of Waterloo, Canada. National Instruments, 11500 N. Mopac Expressway, Austin, TX 78759, 512-683-0100, e-mail: [email protected]

FOR MORE INFORMATION
on the ATML schemas
www.rsleads.com/503ee-181

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!