the measure of innovation
what is CyFlex? design licenses/pricing modularity

I/O

 home
 

I/O Design Considerations

Supported I/O

 

 NATIONAL INSTRUMENTS - virtually

  any National Instrument device 

  can be integrated see NI >>

 

 ANALOG INPUT

  Gantner ebloxx

  Opto22, Optomux, Snap I/O

  National Instruments FieldPoint

  Metrabyte DAS16 family (DAS16G2, DAS1600)

      -Multiplexers (EXP-16, EXP-GP,ISO-4)

      -Computer Boards CIO-MUX16,

  Metrabus family

  Analog Devices RTI-815

  Computer Boards CIO-AD16JR-AT

  Data Translation 2801

  Hewlett-Packard HP-3852 sub-system

  DGH Serial bus I/O family

  Transition Technology (MTL)

     -Universal AI (25mv to 5v and TC)

     -RTD

     -High Level & 4-20ma

     -Strain Gage

  Datel PCI416 family

  Scanivalve - Ethernet thermocouple module

 

 ANALOG OUTPUT

  Gantner ebloxx

  Opto22, Optomux, Snap I/O

  National Instruments FieldPoint

  Metrabyte DDA06, DDA15, DAS16, DAS1602

  Computer Boards CIO-DAC08, CIO-DAC16

  Metrabus MAO-8, MAO-12

  Transition Technology (MTL)

  Opto SnapIO

 

 DIGITAL I/O (any 8255-based board)

  Gantner ebloxx

  Opto22, Optomux, Snap I/O

  National Instruments FieldPoint

  Metrabyte PIO-12, PIO-24, PIO-96, PIO-HV

  ICS PCDIO family (PCDIO24-P, etc.)

  Metrabus family ( MDI-16, MIO-32, MII-32)

  Transition Technology (MTL)

  Opto Optomux & SnapIO

 

 COUNTER/TIMER (AMD9513-based boards)

  Gantner ebloxx

  Opto22, Optomux, Snap I/O

  Metrabyte CTM-05

  ICS DCC20/A, DCC5-P

  Computer Boards CI-CTR10, CI-CTR05

  Opto SnapIO

 

 OTHER I/O

  CyberMetrix is capable of extending support to any COTS 

   hardware with a complete and accurate description of the interface

  protocol including descriptions of the setup, operations and

  shutdown of the equipment.

 

 

  

I/O Design Considerations
 

 

The In's and Out's of I/O

Cyflex's unique architecture is largely insensitive to the use of specific IO.  This is important to the user in maintaining flexibility and cost controls.  Several methods are used in the architecture to abstract and isolate the unique characteristics of a specific set of IO. This allows the architecture to be equally well applied as a software upgrade to existing systems as it applies to new installations. This characteristic also ensures that systems that implement the architecture are capable of supporting new IO installations without impact on non-IO related portions of the system allowing test procedures, reports, user interfaces, etc. to remain unaffected as a result of such a change. This characteristic also allows systems implementing the architecture to provide the user with the same form and function, even though there may be underlying differences in physical IO devices.

 

What Is IO?

IO refers to Input/Output. Systems that test physical devices require inputs to measure sensed physical phenomena for a number of purposes, including: measuring information about the unit under test, feedback for facility controls, and monitoring for equipment or personnel safety and regulatory compliance. Such systems require outputs to control the unit under test, control the environment, control remote sub-systems, and provide other stimuli or information required to conduct a test.

The IO interface for a system can take several forms: The system software can deal directly with registers on electronics boards, interface to existing libraries, or interface with equipment through a digital bus (serial interface, ethernet, etc.).

 

What Are Architectural Considerations for Effectively and Efficiently Managing IO?

There are significant benefits to optimally managing IO interfaces. Optimal management includes achieving an appropriate balance in the system between various factors including: cost, measurement capability, throughput, range, ease of use, and maintainability.

  • Cost: A test system should support a cost-effective IO sub-system. For systems that will be implemented in large volumes the cost of IO can become a dominant factor in analysis that looks at trade-offs of various options. Economic analysis of IO typically includes a total cost analysis: e.g. acquisition costs for IO, installation costs for IO and associated wiring, maintenance costs (repair and replacement costs as well as down time costs), and calibration costs.  An architecture that is largely insensitive to IO can support an appropriate IO set based on decisions that are not dominated by the architecture’s ability to support the IO but rather dominated by these other factors.

  • Measurement capability: A test system should support the measurement capabilities required for both present and reasonably anticipated future needs. The purpose of a test and measurement system is typically to develop or validate products. This typically requires experimentation. Understanding and applying measurement capability is important to conducting and analyzing modern experiments (design of experiments, Taguchi, analysis of variations). A test system’s architecture should support the optimal measurement capability of IO used in the experimentation and ensure that there is no degradation in measurement variation.

  • Throughput: IO is often selected for its throughput (e.g. samples per second). A test system’s architecture should support the throughput for which an IO set was selected and any reasonably anticipated increases to throughput needs that may result from IO replacement. There are many architectures that are incapable of supporting the maximum throughput of an IO device.

  • Range: IO is often selected for the variety of situations in which it can be applied. For example IO can support varying modes of operation (e.g. continuous, burst), sampling ranges (e.g. 0-50mv, +/- 10 V, etc), channel types (e.g. thermocouples, RTDs, pressure transducers, etc.). A test system’s architecture should support the range for which an IO set was selected and any reasonably anticipated changes in range that may result from IO replacement. There are many architectures that are incapable of easily supporting varying uses of an IO device.

  • Ease of Use: Any system should allow end users to easily accomplish their goals.

  • Maintainability: Many systems and software incur the majority of costs during the operation and maintenance of the system due to changes in applications, capability, output needs, etc. Appropriate architecture and design can eliminate or mitigate the impact of change -thereby improving the ability to maintain a system.

What Architectural Decisions Address These Needs?

CyberMetrix uses the driver layer of its Flexible Test System Architecture to address these considerations.

  • Driver Layer: The driver layer abstracts the IO interface and captures sensitivities to unique sets of IO. Two fundamental elements are used to implement this: software that interfaces with the IO, and data that configures the driver for a specific test purpose.

  • Driver Software: The software that interfaces with the IO (the driver) is responsible for translating the abstracted IO needs into device specific instructions required to implement those needs. Typically there is a single instance of a driver for each physical interface (card). Each driver is developed specifically for a given physical IO device - it can therefore be implemented in a manner that addresses the throughput, measurement capability, and range of that device.

  • Configuration Information: A first set of data (configuration information) describes the hardware and allows the hardware features used in a specific implementation to be data driven (e.g. interrupt numbers, IO addresses, DMA channels, etc., representation of data in the raw IO area, channel counts and mapping, etc.).

  • Sampling Information: A second set of data (sampling requirements) describes the sampling needs for a given test or system implementation (e.g. sampling rates, channels to sample, modes of operation, triggering conditions, etc.)

This partitioning generally addresses all of the considerations identified above. Providing a data driven interface with a one-driver-per-interface model ensures that IO can be mixed and matched, and configured to meet a specific purpose. This supports cost effectiveness and maintainability. Ease of use is achieved through isolating the end user from the IO. From the end users’ perspective, IO is sampled according to needs without requiring an understanding of channel mapping, machine resources, or other issues that relate to physical IO implementation. From a developmental and administrative perspective, the use of a data-driven model provides opportunities to implement a change (for example adding a new channel to the system) without modifying any software.

 

Architectural View

More information is available by registering with CyberMetrix.  <REGISTER HERE>   

 
 

CyberMetrix Home Page

Email our Sales Dept.

  

back to top