Electronic circuits are typically constructed in the form of a printed circuit board (PCB) that includes a plurality of electronic components soldered to a circuit board substrate having conductive traces interconnecting various device terminals to form an electrical circuit.  As PCBs and the implemented electrical circuits thereof are often complex, board testing at manufacture has become increasingly automated.  In this respect, board testing apparatuses have evolved from simple I/O functional testers that connect to I/O connectors of a populated PCB for high level automated functional testing, to test fixtures that include probe pins for making electrical contact with all or some of the circuit nodes of a tested board for performance of high level and lower level testing, to integrated testing devices that provide for automated testing of a PCB without the need to externally probe individual circuit nodes of the tested board. 
The testing of electronic circuits in boards and devices is typically controlled by Testing Automation Tools, which support the steps needed to proceed from a definition of the test algorithm to the actual testing operation.  In order to facilitate testing automation, testing resources often are embedded inside the boards and devices, and can be accessed using a standardized interface, usually called a Test Access Port (TAP).  This has the effect of limiting the pin count and rationalizing resource access and management.  In general, most of the existing standards offer one or more languages that can be used to describe the resources inside the system under test (SUT), and which can be used as inputs to Testing Automation Tools.  These Testing Automation Tools can apply their own algorithms in order to generate testing sequences exploiting the TAP.  These testing sequences can then be used by a Test Control Unit (TCU) to command the TAP and execute the testing operations.  The features and performance of the testing operations depend on each of these elements, namely, the access standard, the data format, and the TCU implementation. 
The Joint Test Action Group (JTAG) has developed a circuit board testing standard, denoted as IEEE 1149.1.  IEEE 1149.1 specifies a Test Access Port (TAP) for testing circuit boards.  IEEE 1149.1 supports Boundary Scan (BS) testing of hardware via test devices included on the tested circuit boards.  Boundary Scan testing involves controlling and monitoring boundary pins of a JTAG-compatible device under the control of software to provide test coverage beyond that which might otherwise be available.  Further, Instruction JTAG (IJTAG) is being standardized (denoted as P1687) to overcome existing JTAG limitations associated with moving from board-level JTAG to chip-level JTAG. 
JTAG and IJTAG may be used by Automated Test Generation (ATG) tools to test chips and electronic devices.  JTAG presents a simple 5-wire TAP that allows serially access, with minimal overhead, to resources implemented inside a chip.  The access infrastructure can then be described into a specific language such as the Boundary Scan Description Language (BSDL), which can be used by many commercial TGTs to generate testing vectors.  These testing vectors are typically saved in a format called Serial Vector Format (SVF), which enables a high-level description of the basic operations of the 1149.1 TAP.  A more complex alternative to SVF is STAPL, which extends the vector operations of SVF to allow for basic flow control (if-then-else) and arithmetic operations on the test vectors.  A JTAG-compliant TAP receives commands from a SVF or STAPL player, and generates simple Go/NoGo results which can later be interpreted offline. 
Disadvantageously, these existing approaches have many limitations.  A first limitation is in the data format, because the test player does not have any knowledge of the system under test and, therefore, can perform only very basic operations.  A second limitation is that interactive testing (local or remote) cannot be supported; rather, any testing results must be examined offline.  Further, these existing approaches are implementation-dependent and are typically proprietary.