TestPad Test & Measurement Software technology concepts   Instrument Communication Interface Abstraction (Connection). Requirements: Connection to a Test Instrument must be instrumentation interface independent (GPIB, Serial, TCP/IP, USB etc.). There should be the same way to open/close and send/receive messages over any instrumentation interface/protocol, so connection abstraction most importantly should have only open()/close() and read()/write() methods and any code using connection must work over any instrumentation interface/protocol. It should be possible to add I/O communication protocol layers over the instrumentation interface communication, such as Telnet over TCP/IP. There must also be connection simulation capabilities. Implementation: To hide instrumentation interface details the Virtual Instrument Software Architecture (VISA-COM) library is used, and secondly, the test engine configuration database keeps values of interface specific VISA attributes behind a connection logical name, so that test engine run-time services configure/call the VISA run-time for a specific instrumentation interface on behalf of the client code. The I/O communication protocols layer is implemented by independent software components with in & out connection interfaces, and configuration of this layer for a particular connection is reflected in the test engine configuration database. Connection simulation is powered by an expression definition, or by saving actual connection run-time queries into the connection simulation database and generating ‘simulated’ responses from this database in a simulation mode. The COM, .NET and Web Services seem to be the right choices to expose an Instrumentation Interface Abstraction (Connection), since almost all development environments are compatible with these technologies.   Test Instrument Abstraction (Device). Requirements: A Test Instrument software interface (device properties & methods) must be defined according to an instrument role within the Test Station, rather than the instrument capabilities (classic Instrument Driver design). This approach gives the highest possible Instrument Interchangeability model, which is more flexible than VXI plug&play or IVI drivers model, where you have to use the driver’s API in the test code and can interchange instruments only across similar instrument models or types. There must also be instrument simulation capabilities, and a possibility to merge a few instruments into one logical device. Implementation: The COM, .NET and Web Services seem to be the right choices to expose a Test Instrument software interface, since almost all development environments are compatible with these technologies. Most of the test instruments have a message-based query communication, so to expose Test Instrument functionality as a COM/.NET interface we have to convert in/out messages into the proper COM/.NET representation according to the instrument role-specific Test Instrument Abstraction interface. Clairsoft has developed state of the art technology to generate/parse messages of any format into the COM/.NET calls. It is based on the XML Schema language, and does not require any user code to generate a sending message using provided input parameters and to parse the device response back into a usable data format. GUI-based interactive message definitions therefore can be used to generate a COM/.NET dll adapter provider, which will "adapt" message-based communication into the COM/.NET calls. Instrument simulation capabilities are accomplished by the fact that every instrument property or method can be implemented as a script code with expressions instead of an actual communication with an instrument.   Measurement Abstraction. Requirements: The Test Station (Measurement System) should know how to take a measurement of a UUT signal without a requirement for any programming, based on the UUT pin ID and type of measurement units to be measured. So, information about available test instruments, and their capabilities and connections via switches/routers must be built into the system to provide run-time measurement services. For example, parameterized tests in such a measurement system can be generated and executed by the test engine run-time directly from test requirements provided in the form of "UUT pin - Measurement units - Validation constraint" with no other coding or scripting. Implementation: The Test Engine run-time provides the following services: - Signal auto routing/switching to the required test instrument by specifying a UUT in/out pin and measurement units to acquire/generate a signal (with an ability explicitly to specify transit elements when required). The configuration database of the Test Station schema is used to select one of the available instruments associated with the measurement units and secondly, a path from this instrument to the UUT. Switches/routers are controlled by the Test Engine based on the standardized switch API interface. - Taking into account the path calibration loss/offset for a measurement. The configuration database contains the power loss of every connector+socket segment to calculate the total path loss. - Performing required measurement conversions from an instrument supplied units to the selected default units of a particular type. The configuration database contains user extensible measurement conversion table.   to be continued for test data validation, test specs associations, test results processing, test & measurement database requirements, test executive, tracing & logging and more...   Please let us know if you are interested in Test & Measurement software architecture discussions and/or development.     Sincerely,   Clairsoft Team.