This schema is specified in IEEE 1671-2006, "IEEE Trial-Use Standard
for Automatic Test Markup Language (ATML) for Exchanging Automatic Test
Equipment and Test Information via XML."
This schema is a World Wide Web Consortium (W3C) Extensible
Markup Language (XML) binding of the ATML Hardware Common component defined in IEEE
1671-2006, "IEEE Trial-Use Standard for Automatic Test Markup
Language (ATML) for Exchanging Automatic Test Equipment and Test
Information via XML."
The purpose of this schema is to provide hardware unique types and attributes
for ATML schemas. This schema uses the W3C XML Schema definition
language as the encoding. This allows for interoperability and
the exchange of ATML component instances between various systems.
This schema shall not be modified but may be included in
derivative works.
Copyright (c) 2006 Institute of Electrical and Electronics
Engineers, Inc.
Source: http://grouper.ieee.org/groups/scc20/tii/ATML/Schemas/Current/HardwareCommon.xsd (2007-11)
USE AT YOUR OWN RISK
Starting index for the items.
Number fo identical items
Specifies the value to increment by when calculating the value with which the replacement character is replaced. Allows for defining items where paired items have different characteristics. Defaults to 1.
Character replaced with calculated index when repeated items are expanded.
Identifies the type of error.
Abstract type used to describe hardware entities. Derived types include Instrument Description, UUT Description, Test Station Description, etc.
This collector permits listing any subcomponents of the subject Hardware Item.
Unbounded set of elements describing and identifying each subcomponent. At a minimum, there must be a description and a Part Number.
ID for the component
This collector permits listing the parents of the Hardware Item.
Unbounded set of elements describing the Hardware Items into which this Hardware Item can be used as a component.
ID for the component
The driver type is specified by providing a type that derives from the "Driver" abstract type. The derived type includes any information that is specific to that driver type. The schema includes derived types for several different driver types.
Identifies any dependencies.
Identifies the platform requirements for using this driver.
The control language is specified by providing a type that derives from the "ControlLanguage" abstract type.
Any software tool that comes with the item, e.g., Calibration Utility, Soft Front Panel, etc.
Identifies any dependencies.
Name of the configuration option. Configuration options are values the user can modify that persist after a power-cycle.
Keyword-value pair for identifying manufacturer item defaults.
Identifies the support equipment needed for running calibration.
The calibration procedure.
Specifies how often calibration needs to be executed. The following indications a duration of 2 months, 10 days and 15 hours: P2M10DT15H
List of errors associated with the item.
Warning, error fatal
item, driver
Netlist describing how all the ports in the item are wired together. In the simplest scenario, the capability ports get wired to Resource ports and the resource ports get wired to the item ports.
Abstract type for control language identification Derived types include SCPI and Register
Specifies that the item can be controlled using SCPI commands
Specifies that the item is register based
Specifies that the item can be controlled using some generic control language
Abstract type for drivers. Derived types include VPP, IVI, IVI-C, IVI-COM, etc.
VXI plug and play driver
IVI driver - includes structure for specifying whether the driver is an IVI-C or IVI-COM driver
Name of IVI class(es) provided by this driver
IVI-C driver
IVI-COM driver
ProgID used to instantiate the driver class.
Base type for sub-components of a hardware item
Allows multiple identical items to be described with a single element in an instance document.
Index used to identify the resource.
Describes how the various item entities are connected.
XPath path identifying the node.
ID of the document in which the node is defined. If not speciifed, the node is defined in the same document.
Non-power interfaces.
Test Station cooling requirements.
Used to identify the minimum/maximum version
Used to indicate whether the version speciifed is the minum or maximum version supported.
Details needed to interface with this trigger signal
Free text to give details of this trigger signal
Details of the signal that will generate the trigger
Name should be descriptive of what this signal does
Base type for trigger properties
Properties if trigger comes from an analog signal
Properties if trigger comes from a digital signal
Properties if the trigger is intiated by a SW call
Properties if the trigger is a LAN trigger
Describes the analog voltage needed for the trigger
Need to have edgeDetection or levelDetection or both
Direction and type are important to know what interfaces this trigger can be routed to/from.
Created TriggerPortType to allow capturing of LAN and SW trigger types.
Collector element used to group list of capabilities and the mapping of capabilities to ports. The capabilities can be defined inline or referenced from an external document.
Base type used to describe capabilities
Describes how capabilities are mapped to resource ports
Conditions under which the specifications are measured. These conditions apply to all specifications. Each individual specification can add additional conditions, or override/replace the any of these conditions.
Specifies traceability information for all specs
A grouping of specifications that share a set of conditions.
A short (one or two sentence) textual description of the specification
A rigorous (mathematical) description of how the specification is defined and measured
Conditions under which this specification is measured.
The limits for the specification
Specification limit
The data for the graph can be specified by proving the URL of the file containg the data or image of the graph, or by specifying the data using an extension. For example, using the XML standard for describing graphis or perhaps the XML representation of a PDF file.
Any additional information that is necessary to clarify the specification. This includes information that is contained in footnotes of the datasheet
Options that are required for this spec to be valid
Otions that make this spec invalid
A short (one or two sentence) textual description of the specification group
Conditions under which the grouped specifications are measured. Each individual specification can add additional conditions, or override/replace any of these conditions.
Guaranteed: If the item does not meet this spec, it is considered broken and will be repaired under warranty
Typical: Most items would be expected to meet this spec, but it is not guaranteed
States the expected percentage of instruments that will meet the spec
Nominal: Characteristics that are true by design, but not measured or tested.
Characteristic: A ball-park figure that describes the type of performance that may be expected, but not verified with rigorous statistical analysis or measurements
Feature: A description of a feature, which is not actually a spec but is the sort of thing that is often included in the spec sheet