ATML

1
ATML

• IVI Signal Capability Model

2
Objective

• Describe a signal-oriented model for requirements
  and capabilities in support of resource
  allocation
• Currently used with ATLAS
• Can be used with other languages / ADEs
• Used in IVI Signal Interface specification
• While not perfect, it works
• Validated through usage
• Can be enhanced to overcome limitations

3
Principle

• Each signal has a signal type
• Signal types definitions specify signal
  parameters (attributes)
• Requirements and capabilities are expressed in
  terms of range, resolution and accuracy of signal
  parameters
• Allocation algorithm searches for a resource
  whose capabilities match or exceed requirements

4
Example

• Definition of Signal type AC SIGNAL
• Signal parameters

5
Example...
not in use

• Requirement
• Source of AC SIGNAL
• VOLTAGE
• Range 0V to 2V
• FREQ
• Range 100Hz to 1MHz
• Resolution 1Hz
• Accuracy 0.1Hz
• CONN P1-1, P1-2

• Capability (FGen)
• Source of AC SIGNAL
• VOLTAGE, controllable
• Range 0V to 5.0V
• Resolution 1mV
• Accuracy 0.1
• FREQ, controllable
• Range 10Hz to 10MHz
• Resolution 1Hz
• Accuracy 0.05Hz
• Source of AM Signal ...

signal paths can be closed
6
Specifying requirements

• ATLAS
• Implicit, in signal statements
• APPLY, AC SIGNAL,
• VOLTAGE 1V, FREQ 100HZ, DC-OFFSET 0V,
• CNX HI P1-1 LO P1-1
• Explicit REQUIRE statement
• Example AC sweep changes frequency range must
  be indicated in advance
• REQUIRE, AC SUPPLY, SOURCE, AC SIGNAL,
• CONTROL,
• VOLTAGE RANGE 0V TO 2V,
• FREQ RANGE 100HZ TO 1MHZ BY 1HZ ERRLMT
  0.1HZ,
• CNX HI LO
• APPLY, AC SIGNAL USING AC SUPPLY,
• VOLTAGE 1V, FREQ 100HZ, DC-OFFSET 0V,
• CNX HI P1-1 LO P1-1
• CHANGE, ...

7
Specifying requirements...

• Note In many situations TPS developers specify
  directly the instrument to be used (in ATLAS,
  USING)
• The resource allocator can still verify
  requirements against capabilities
• An allocation error is generated if the
  capabilities of a replacement instrument do not
  satisfy requirements.

8
Specifying requirements...

• IEEE 1641, Implicit, with existing BSC or TSF
  components
• Set STD CreateObject("STD.Resource")
• Dim acInput As AC_SIGNAL
• Set acInput STD.Require("AC_SIGNAL")
• acInput.ampl "1 mV"
• acInput.freq "1 kHz"
• Dim acSig As TwoWire
• Set acSig STD.Require("TwoWire")
• acSig.hi "PL1-1"
• acSig.lo "PL1-2"
• Set acSig.In acInput.out
• acSig.Out.Run

Another version of Require() accepts requirements
represented in XML
9
Specifying requirements...

• Test Requirements Documents

10
Describing capabilities

• ATLAS ADEs supporting automatic allocation
  usually a proprietary file format
• IVI Signal Drivers data structure accessible
  through the driver API
• IVI Signal Interface driver API supporting the
  signal-oriented control of instruments
• Note Describes the capabilities of the
  instrument signal driver subsystem
• The performance delivered by the instrument
  depends on how it is configured by the signal
  driver

11
IVI Signal Capability Model

• Simplified
• Signal Driver
• Signal
• Signal Role Source, Sensor, Monitor, ...
• Signal Type (ex. AC SIGNAL)
• Signal Parameter
• Name (ex. VOLTAGE)
• Signal Parameter Role Controllable, Measurable,
  Capability
• Value
• Range Min, Max
• Resolution
• Accuracy AbsPlus, AbsMinus, RelPlus,
  RelMinus
• Signal Port
• Connected Instrument Ports
• Used Subsystems
• Signal ...

12
IVI Signal Capability Model...

• Complete
• Exclusive capabilities
• Ex. DMM can measure DC SIGNAL or AC SIGNAL
• Alternative capabilities
• Ex. DMM can provide voltage_accuracy_1 for
  voltage_range_1 or voltage_accuracy_2 for
  voltage_range_2
• Interdependent capabilities
• Ex. DMM can provide voltage_accuracy_1 for
  frequency_range_1 or voltage_accuracy_2 for
  frequency_range_2
• Support for switch modules and internal switches
  of instruments
• Hierarchical signals
• Ex static digital channel and static digital

13
IVI Signal Capability Model

• Signal Type Specification
• 1641 TSF signals
• 1641 signal attributes
• Amplitude, frequency, DC offset, phase
• Parameters describing signal quality
• Overshoot, linearity, noise, harmonics, etc.
• Parameters for the complementary parameter
• Current, for a voltage source

14
IVI Signal Capability Model...

• The principle is validated through use in ATLAS
  systems
• The implementation was validated through
  prototyping
• IVI signal drivers
• Traditional instruments
• Sound card as synthetic instrument
• Digital instrument
• Serial bus
• Switch
• Signal Object Library
• COM API supports signal-oriented testing with
  GPLs
• Run-time engine provides automatic resource
  allocation and switch path calculation
• TPSs
• Bandwidth test Visual Basic
• Signal transfer tests TestBase test executive,
  IEEE 1641 signals
• Interchangeability demonstration
• Instrument replacement
• Re-hosting

15
IVI Signal Capability Model...

• For more information
• IVI Signal Interface WG page
• http//ivifoundation.org/Member20Login/Signal-Int
  erfaces/default.htm
• Previous drafts - obsolete
• PowerPoint files minutes for past meetings
• Draft 4 of specification (coming soon)
• Requirements applicable to ATML in Groove, Files
  / Working Groups / Instrument Description /
  Requirements Use Cases/ ATML Instrument Use
  Cases and Requirements TYX
• Originate from TYX experience with ATLAS
  implementations and IVI Signal Interface design
  process
• Prototype schema sample instance documents in
  Groove, Files / Working Groups / Instrument
  Description / Requirements Use Cases/ IVI
  Signal Capability Schema for ATML.zip
• XML equivalent of data structure exposed by IVI
  Signal Driver API

16
Limitations

• Capabilities available at UUT pins are often
  different from the capabilities of the individual
  instruments
• See Mike Seaveys posting to Test Configuration
  discussion tool in Groove
• Possible solutions
• 1. Use the same model to express capabilities at
  the UUT interface use these capabilities for
  allocation
• Problem capabilities may also depend on signal
  paths through the switching subsystem
• 2. Describe in ATML schemas the capabilities of
  switching subsystem, cables, receiver, ITA the
  allocator calculates the capabilities at the UUT
  interface
• Problem calculation may be complex (ex.
  frequency-dependent transmission characteristics)
  or imprecise

17
Limitations...

• Signal-oriented requirements may be insufficient
  for measurement operations
• Signal-oriented requirements describe the signal
  waveform when the UUT is good
• Measurement may be difficult or impossible to
  perform when the UUT is bad
• Example because the signal is distorted, the
  trigger levels calculated based on the good
  waveform are wrong the scope does not synchronize

18
Limitations...

• The model relies on external signal type
  definitions. This may be impractical in the case
  of complex waveforms, due to their infinite
  diversity.
• Complex waveforms are typically generated with
  ARBs or synthetic instruments. Thus, the waveform
  shape is no longer an allocation criterion (any
  shape can be generated).
• Allocation is typically based on signal
  parameters that are not directly related to the
  shape, ex. maximum sampling frequency, amplitude
  resolution, etc.
• Sampled signals with arbitrary waveforms are
  supported in ATLAS by the single signal type
  WAVEFORM
• Conclusion this is not a limitation

19
Support in ATML (suggested)

• Requirements
• Test Description
• Possibly, schema for XML snippets to be embedded
  in test program code
• Capabilities
• Instrument Description (same spec, or separate
  spec)
• Tester Configuration
• TBD (maybe Interface Adapter) ...
• Note Models for requirements capabilities are
  similar but not identical
• Separate schemas will likely be needed
• Reusable types may end up in Common

20
Conclusions

• A powerful signal-oriented model for requirements
  and capabilities exists
• Simple enough to allow interchangeable
  implementation of resource allocation
• Ability to handle complex use cases validated
  through usage
• Can be enhanced to overcome existing limitations
• Necessary for supporting existing ATLAS systems