Automated test equipment and methods using device-specific data

Abstract

An automated test equipment comprises a tester control configured to broadcast and / or specifically upload input data and / or device specific data, including keys and / or certificates and / or IDs and / or configuration information, to a matching module. The automated test equipment further comprises a channel processing unit configured to transform the input data using the device specific data to obtain device under test adapted data for testing a device under test. The channel processing unit is further configured to process the DUT data using the device specific data to evaluate the DUT data. A method and a computer program for testing one or more devices under test in an automated test equipment are also disclosed.

Description

Technical Field

[0001] Embodiments of the present invention relate to, for example, automated testing equipment for multi-site testing.

[0002] According to another embodiment of the present invention, there is a method for testing a device under test.

[0003] According to another embodiment of the invention, a computer program is used to perform the method.

[0004] In general, embodiments of the present invention relate to providing efficient and secure device-specific communication for multi-site testing.

[0005] Furthermore, embodiments of the present invention relate to automated test equipment and methods for providing efficient and secure device-specific communication for multi-site testing. Background Technology

[0006] In traditional device testing concepts, automated test equipment is typically used to test the device under test (DUT). The test interface between the DUT and the automated test equipment can use different communication protocols, such as iJTAG, RSN, or IEEE 1687. It has been recognized that while the test program can be identical for all DUTs during test execution, the test execution and test data can differ. Within this framework, multi-site testing is a well-known method for testing multiple DUTs in parallel, reducing overall test time and thus lowering costs. However, it has also been found that multi-site testing efficiency is compromised, for example, due to the (high) computational workload required for data stream computation. Other threats have also been identified, such as the limited broadcast efficiency resulting from device-specific communication and direct device interaction via, for example, protected or encapsulated interfaces.

[0007] Furthermore, traditional device testing concepts utilize a central processing unit (CPU) that includes memory and computing units. It has been found that in centralized channel architectures, data needs to be transmitted and computed on the CPU, which cannot perform local data conversions (e.g., device-specific, DUT-specific), leading to high communication overhead for device-specific communications.

[0008] Techniques for using device-specific communication via channel processing units have been publicly disclosed. For example, US2018 / 0196103 A1 discloses an automated test apparatus system capable of performing semiconductor device testing. JP2009508142A discloses a tester for testing devices under test (DUTs). US 2019 / 0383873 A1 discloses a test and measurement apparatus for testing multiple DUTs. US 2004 / 0044939 A1 discloses a system for testing different types of semiconductor devices.

[0009] Given this situation, a testing concept is needed that offers an improved compromise between complexity, test throughput, and security. Summary of the Invention

[0010] An embodiment of the present invention provides an automated test apparatus for testing one or more devices under test (DUTs), which includes tester controls.

[0011] The tester control includes, for example, a centralized test process management system configured to broadcast and / or specifically upload device-specific data to the matching module. This device-specific data may include keys and / or certificates and / or IDs and / or configuration information. For example, the tester control may broadcast the same data simultaneously to multiple attached channel processing units.

[0012] In addition, centralized test process management can be configured, for example, to broadcast and / or specifically upload input data to the matching module (e.g., incoming tester command stream, or DUT stream, or broadcast data, or shared data, or data equivalent to different DUTs, or common expected result data).

[0013] The automated test equipment also includes a channel processing unit, which is coupled to the tester control, for example, via the tester data bus.

[0014] Furthermore, the channel processing unit is configured to use local device-specific data (e.g., local device-specific information and / or keys and / or certificates and / or IDs and / or configurations) to transform (or process) input data (e.g., incoming tester command streams, or DUT streams, or broadcast data, or shared data, or data equivalent to different DUTs, or common expected result data) to obtain device-under-test adaptation data (e.g., protocol-aware data or data adapted to a single device under test or expected result data adapted to the device under test) for testing the device under test (e.g., data provided to the device under test or for evaluating response data from the device under test).

[0015] Alternatively or additionally, the channel processing unit is configured to process (e.g., convert, analyze, or decrypt using a device-specific key, or unpack from the protocol using device-specific (e.g., packet counters, device IDs)) DUT data (e.g., data from the DUT; e.g., data from the protocol determined by device-specific data, such as a device-specific key), and use (e.g., local) device-specific data to test or evaluate the DUT (e.g., by extracting the communication payload or by evaluating data transmissions from the DUT, or obtaining device-independent or non-DUT-specific information). Therefore, device-specific data (e.g., keys and / or certificates and / or IDs and / or configurations) is configured to be stored, for example, in local memory, such as the local memory of the channel processing unit.

[0016] The described automated test apparatus is based on the finding that excessive limitations in test throughput within an automated test apparatus can be overcome by using device-specific processing in one or more channel processing units (the excessive limitation is caused by bandwidth constraints between the tester controls and the channel processing units).

[0017] Therefore, by using device-specific data stored locally in the channel processing unit (or even using different device-specific data stored in different channel processing units) to transform the input data of the channel processing unit that can be provided by the tester control, it is possible to obtain device-specific device-under-test (DUT) adaptation data for testing different DUTs in automated test equipment that includes multiple channel processing units, while avoiding excessive data transmission to different channel processing units.

[0018] For example, by performing device-specific adaptation of test data in the channel processing unit using device-specific data, it is no longer necessary to forward different (device-specific adapted) test data to the channel processing unit. Instead, it is sufficient to transmit common (identical) test data and a (relatively) small amount of device-specific data to the channel processing unit, where the common test data can be broadcast (e.g., in a bandwidth-saving manner) to the channel processing unit. Therefore, the amount of data to be transmitted from the tester control to the channel processing unit can be much smaller than in conventional solutions where individual (device-specific adapted) test data for all devices under test are transmitted from the tester control to the channel processing unit.

[0019] Similarly, by using device-specific data in the channel processing unit to evaluate DUT data, it is no longer necessary to transmit different device-specific verification data (describing the expected DUT data) to the channel processing unit, or to forward the complete DUT data to the tester control for evaluation. Instead, by using device-specific data (which may include a relatively small amount of data) stored locally in the channel processing unit (potentially along with common data, typically used to evaluate DUT data for different devices under test), the amount of data transmitted from the channel processing unit to the tester control can be reduced. For example, device-specific data can be used to decrypt DUT data and / or implement DUT-specific communication protocols.

[0020] Furthermore, a high level of security and confidentiality can be achieved by storing device-specific data directly in the channel processing unit. For example, storing device-specific data in the channel processing unit can be more economical than storing it in the tester control, because the channel processing unit is less likely to be attacked due to its typically very specific embedded architecture.

[0021] Furthermore, it has been found that, given the processing capabilities available in the channel processing unit, it is generally easy to implement processing using device-specific data within the channel processing unit. Additionally, the channel processing unit is typically more suited to real-time (or instantaneous) processing than tester controls, thus enabling it to handle processing tasks.

[0022] In summary, the concepts discussed above offer a good trade-off between complexity, test throughput, and security.

[0023] Furthermore, the described automated test equipment is based on the finding that the concept is efficient in a secure communication environment, which can facilitate secure multi-site DUT testing through the use of advanced security architectures. Security mechanisms may include, for example, encrypting / decrypting DUT (device-specific) communications to prevent unauthorized access to internal device structures by test and debug interfaces. Additionally, functional interfaces that remain active after testing may require protection. Further security mechanisms could include, for example, authorization or authentication, where authorization grants a certain level of access (e.g., only a specific test can be applied to the DUT), and authentication verifies, for example, the user's identity. Furthermore, communication between the DUT and the channel processing unit can be further protected by using, for example, packet counters and / or error correction codes and / or error identification codes. This ensures the highest possible security in a multi-site test environment. Therefore, using the above concepts, device-specific processing can be performed in the channel processing unit (e.g., converting input data of the channel processing unit using device-specific data, such as device-specific encryption or authorization information). This can reduce the processing load of the tester control and the amount of data transferred from the tester control to the channel processing unit, and vice versa. Furthermore, security can be improved by storing secret information in the channel processing unit, which is less vulnerable to security attacks than the tester control.

[0024] Furthermore, this invention allows for efficient device-specific communication, where communication between the tester control and the channel processing unit is performed in a device-agnostic manner as much as possible. This can be achieved, for example, through a result analysis method where the tester control broadcasts input data to different channel processing units via the tester data bus. In the different channel processing units, the input data can be compared with corresponding (e.g., extracted) result data from the DUT, and the corresponding test results are stored in memory. In cases where the corresponding test result (upstream result data) differs from the input data, the difference between the corresponding test result data and / or the input data can be, for example, compressed and transmitted to the tester control. The data to be transmitted to the tester control can additionally (or optionally) include a DUT signature. In summary, the result analysis method on the channel processing unit can minimize test time by reducing bus traffic and CPU requirements.

[0025] For example, further efficiency and security can be achieved by using a sandbox channel processing unit that utilizes its separate memory and computing power within the channel processing unit to provide local execution of tester commands; thus, device-specific functions can also be updated by uploading third-party software to enable efficient device-specific computational steps.

[0026] In a preferred embodiment, the channel processing unit is configured to communicate with one or more DUTs via a device-specific channel and a DUT interface. This is for transmitting device-under-test (DUT) adaptation data to the DUT and / or receiving DUT data from the DUT. The DUT interface may be, for example, one of an iJTAG interface (IEEE 1687 interface), an RSN interface, or a debug interface, or a high-bandwidth interface such as an IEEE 1149.10 interface, a SATA interface, or a USB interface.

[0027] In a preferred embodiment, the channel processing unit is configured to communicate with the central tester control using a tester interface (e.g., a data bus, interface, or proprietary bus). For example, the tester interface may be one of an iJTAG interface (IEEE 1687 interface), an RSN interface, or a debug interface, or a high-bandwidth interface such as an IEEE 1149.10 interface, a SATA interface, or a USB interface. However, any other type of interface, such as a fast parallel interface or an Ethernet interface, may also be used.

[0028] In a preferred embodiment, the tester control is configured to broadcast input data to multiple channel processing units via the tester interface. When broadcasting input data (e.g., incoming tester command streams, DUT streams, broadcast data, shared data, data equivalent to different DUTs, or common expected result data), the same input data can be transmitted to multiple channel processing units. Furthermore, broadcasting can be significantly more bandwidth-efficient than individually transmitting the same data to different channel processing units, and even more bandwidth-efficient than individually transmitting different (device-specific) data to different channel processing units.

[0029] In a preferred embodiment, the tester interface is a tester data bus coupled to the tester control and multiple channel processing units. Specifically, equivalent data that can be adapted by the device communication unit in a device-specific manner can be efficiently transmitted from the tester control to the device communication unit via this tester data bus.

[0030] In a preferred embodiment, the channel processing unit includes volatile storage (e.g., memory) and / or non-volatile storage (e.g., solid-state drive) and a computing unit (e.g., CPU, ASIC, FPGA). Furthermore, the channel processing unit is configured to store device-specific data in its storage and use the computing unit to transform input data sent from the tester control. For example, by using device-specific data, input data can be transformed into device-under-test (DUT) adapter data. Alternatively or additionally, the channel processing unit is configured to use the computing unit to process, for example, DUT data sent from the DUT. DUT data processing includes, for example, data compression and / or data encryption and / or including generated signatures, etc.

[0031] By storing device-specific data in the memory of the channel processing unit and using it to generate device-specific test data (which can be performed before DUT testing or even "on the fly" during DUT testing), the need to exchange large amounts of device-specific test data between the tester control and the device communication unit can be overcome. Instead, only a relatively small amount of device-specific data needs to be uploaded from the tester control to the device communication unit, and the device communication unit can use its own computing unit (e.g., based on device-agnostic public test data) to generate a relatively large amount of DUT adaptation data. Similarly, the channel processing unit can, for example, use the device-specific data to extract device-agnostic result data, such as by decompressing or decrypting DUT data received from the device under test, where this "device-agnostic" result data can, for example, be used to classify the DUT as passed or failed. Therefore, the processing load on the tester control can be kept low, and the amount of data transmitted via the tester interface can be kept small, thus avoiding a bottleneck.

[0032] In a preferred embodiment, the channel processing unit includes one or more sandboxes, and the sandboxes are configured, for example, to execute commands using separate memory and separate computing power. In other words, a sandbox is a virtual environment that executes its own commands and uses its own data, for example. Furthermore, one or more sandboxes may be configured, for example, to transform input data and / or analyze results received from the DUT using device-specific data (e.g., with separate computing power). For example, the use of sandboxes can enable the channel processing unit to execute one or more programs adapted to the DUT in a secure manner. For example, programs running in the sandbox may be provided by the user of the automated test equipment (rather than by the manufacturer of the automated test equipment) and may, for example, use device-specific data to perform the aforementioned input data transformations without the risk of interfering with the essential functionality of the channel processing unit. In other words, the sandbox may, for example, "isolate" the user-provided programs adapted to the DUT from other functions of the channel processing unit (where well-controlled data exchange is still possible). Therefore, one or more user-provided programs can run securely within one or more sandboxes of the channel processing unit to perform device-specific processing on data to be provided to and / or received from the DUT.

[0033] In a preferred embodiment, the channel processing unit includes multiple sandboxes, wherein the sandboxes are configured to communicate with the host channel processing unit using one or more protected interfaces, such that the different sandboxes are isolated from each other. This provides a high degree of security and stability.

[0034] In a preferred embodiment, the channel processing unit includes one or more sandboxes, wherein the sandboxes are configured to perform device-specific functions using device-specific data (e.g., encrypting input data, input data common to multiple DUTs, using a device-specific encryption key or device-specific certificate, or decrypting DUT data using a device-specific decryption key or device-specific certificate, or processing input data or DUT data using other device-specific information (such as a device-specific identifier)). Therefore, the sandboxes can support device-specific processing.

[0035] In a preferred embodiment, the automated test equipment is configured to upload software to one or more sandboxes to allow for device-specific processing of input or DUT data using the sandboxes. Therefore, device-specific functionality can be updated by uploading from third-party software, enabling efficient device-specific computational steps (e.g., communication with a specific DUT interface that is known to the device configuration).

[0036] In a preferred embodiment, the channel processing unit is configured to implement a device-specific communication protocol using device-specific data to protect (e.g., using encryption / decryption, and / or using error detection mechanisms and / or error correction mechanisms and / or authentication mechanisms) the communication between the channel processing unit and the device under test (DUT) (e.g., one-way or two-way communication). Therefore, separate test access to the safety-critical device under test can be achieved without compromising security and without creating excessive load on the interface between the test control and the device communication unit.

[0037] Furthermore, the protocol used to communicate with the corresponding DUT is, for example, programmable in hardware or software, and therefore reconfigurable. In the case of performing protocol-aware testing, it may be necessary to efficiently track the state of the protocol. Communication between the DUT and the channel processing unit can be protected by one or more of the methods described above. The channel processing unit can, for example, detect and correct correctable errors. Error detection mechanisms may, for example, be cyclic redundancy check (CRC). Error correction mechanisms may, for example, be (or include) Viterbi-decoded forward error correction codes or block codes.

[0038] In a preferred embodiment, the channel processing unit includes a computing unit (CPU, ASIC, FPGA) configured to interact with one or more DUT interfaces. Furthermore, the computing unit is configured to perform device-specific encryption on input data (e.g., from a device communication unit) to obtain DUT adaptation data, and / or perform device-specific decryption on DUT data, and / or perform error detection (e.g., error identification) (i.e., detecting errors in the DUT data) on the DUT data, and / or perform error correction on the DUT data (i.e., to reconstruct the original DUT data sent from the DUT), and / or use one or more packet counters to implement a communication protocol to obtain DUT adaptation data or evaluate DUT data, and / or use one or more device-specific or device-unique identifiers to implement a communication protocol to obtain DUT adaptation data or evaluate DUT data. By implementing one or more such functions on the channel processing unit, the load on the tester control (e.g., which can coordinate the testing of multiple DUTs using multiple channel processing units) is reduced, and the amount of data on the tester interface can be kept relatively small.

[0039] In a preferred embodiment, the channel processing unit includes a computing unit (CPU, ASIC, FPGA) configured to implement the communication protocol in hardware (ASIC / FPGA) and / or software. In other words, the channel processing unit can be configured to communicate with the DUT via a specific protocol supported by the corresponding DUT, wherein the specific protocol can be programmed in the hardware or software of the computing unit. Both hardware and software solutions have their specific advantages. While hardware implementations are generally faster and may need to accommodate very high-bandwidth communication interfaces, software implementations are generally more configurable.

[0040] In a preferred embodiment, the tester control (e.g., a security certificate unit and / or key unit, which may be part of the tester control) is configured to acquire (e.g., receive or generate) security certificates and / or keys, broadcast the security certificates and / or keys to one or more channel processing units, and / or specifically upload the security certificates and / or keys to matching channel processing units (e.g., in encrypted form). Therefore, efficient centralized distribution of security certificates or keys can be achieved, which facilitates the use of automated testing equipment in a test environment. On the other hand, confidentiality can be ensured through secure communication between the tester control and the channel processing units, at least for certificates or keys.

[0041] In a preferred embodiment, the tester control (e.g., a security certificate unit and / or a key unit) is configured to obtain (generate) a security certificate and / or key (e.g., an automated test device-specific security certificate or key, such as the public key of the automated test device) and broadcast it to one or more DUTs.

[0042] In a preferred embodiment, the communication protocol implementation in the channel processing unit is configured to use one or more of the following:

[0043] • One or more group counters;

[0044] • Handshake with device-specific information (such as device ID);

[0045] • Synchronization communication including timestamps;

[0046] • Implementation of communication standards (e.g., IEEE 1687.x, IEEE 1500, IEEE 1149.x).

[0047] Therefore, communication adapted to a specific DUT can be established. The protocol requirements of the individual DUT (such as packet counter device ID, security certificate, or signature) can be considered, without excessive bandwidth requirements in the communication between the tester control and the channel processing unit.

[0048] In a preferred embodiment, the channel processing unit is configured to store upstream result data (e.g., DUT data from the device under test) and / or analyze the upstream result data (e.g., using expected result data, for example, comparing it with expected result data). The analysis of the upstream result data is to determine whether there is a difference between the upstream result data and the expected result data, which could reflect manufacturing defects on the corresponding DUT. The channel processing unit is also configured to preprocess (e.g., compress) the upstream result data, and / or transmit (forward) the preprocessed and / or compressed upstream result data to the tester control via the tester interface. Therefore, test results can be obtained under low load on the tester control and the tester interface.

[0049] In a preferred embodiment, the automated test apparatus includes multiple channel processing units, wherein the tester control is configured to provide common data to the multiple channel processing units (e.g., simultaneously, e.g., using broadcast, e.g., via the tester data bus). In other words, the tester control simultaneously broadcasts the same (common) data to multiple attached channel processing units.

[0050] Furthermore, different channel processing units are configured, for example, to use different device-specific data associated with different devices under test (DUTs) to convert common data into different DUT adaptation data for different DUTs. Additionally, different channel processing units are configured to use different DUT adaptation data to test different DUTs. Therefore, common data adapted to a specific DUT within a channel processing unit can be forwarded in a bandwidth-efficient manner, thereby keeping the load on the tester interface low.

[0051] In a preferred embodiment, the tester control is configured to provide common stimulus data (e.g., a central data stream, which may define the signals to be output to the device under test, in addition to device-specific characteristics such as device-specific encryption, device-specific identifiers, and device-specific configurations) to multiple channel processing units. Furthermore, the channel processing units are configured to transform the common stimulus data using local device-specific data. Therefore, it is possible to efficiently test multiple devices under test simultaneously while avoiding the tester interface becoming a bottleneck.

[0052] In a preferred embodiment, the channel processing unit is configured to transform common stimulus data using local device-specific data or device-unique data to provide device-specific communication (e.g., encrypted in a device-specific or device-unique manner, or using a device-unique key or device-unique certificate) (e.g., adapted to individual devices). Therefore, the individual characteristics of the device under test (such as certificates, keys, device IDs, etc.) can be efficiently considered.

[0053] In a preferred embodiment, the automated test apparatus includes multiple channel processing units, wherein the tester control is configured to provide common expected result data to the multiple channel processing units (e.g., simultaneously, via broadcast, or via the tester data bus). Furthermore, different channel processing units are configured to use the common expected result data to obtain corresponding test results associated with their respective devices under test (DUTs). Therefore, the channel processing units can determine test results in a decentralized manner, avoiding the transmission of all DUT data to the tester control. Device-specific characteristics can be considered in evaluations using device-specific data, which can also be uploaded from the tester control to the channel processing units before evaluating the test results. Device-specific data can be used, for example, to decrypt DUT data from the DUT, to establish a trusted connection with the DUT, or to evaluate the communication protocols used by the DUT.

[0054] In a preferred embodiment, the automated test apparatus includes multiple channel processing units, wherein the tester control is configured to provide common expected result data to the multiple channel processing units (e.g., simultaneously, e.g., via broadcast, e.g., through the tester data bus). Furthermore, different channel processing units are configured to extract corresponding result data from corresponding DUT data from different DUTs using different device-specific data associated with different DUTs, and compare the corresponding result data with the common expected result data to obtain the corresponding test result associated with the respective DUT. Therefore, distributed processing of DUT data can be performed, thereby avoiding bottlenecks.

[0055] An embodiment provides a method for testing one or more devices under test (DUTs) in an automated test apparatus including tester controls and a channel processing unit. The method includes transforming input data (e.g., a DUT stream; an incoming tester command stream; or broadcast data; or shared data; or data equivalent to different DUTs; or common expected result data) in the channel processing unit using local device-specific data (local device-specific information and / or keys and / or certificates and / or IDs and / or configurations) to obtain DUT-adaptive data (e.g., protocol-aware data; data adapted to an individual DUT; or expected result data adapted to the DUT) for testing the DUT (e.g., data to be provided to the DUT or for evaluating response data from the DUT). The method also includes processing DUT data from the DUT in the channel processing unit (e.g., converting, analyzing, or decrypting using a device-specific key, or unpacking from the protocol using device-specific protocol information such as a packet counter or device ID); (e.g., using protocol data determined by device-specific data, such as a device-specific key) using local device-specific data to test and evaluate the DUT (extracting the communication payload or evaluating data transmission from the DUT) to obtain device-independent or non-DUT-specific information.

[0056] However, it should be noted that the method described herein may optionally be supplemented by any features, functions, and details disclosed herein, which are also related to automated test equipment. It should be noted that the method may optionally be supplemented by these features, functions, and details, either individually or in combination. Attached Figure Description

[0057] Embodiments of the present invention will then be described with reference to the accompanying drawings, wherein:

[0058] Figure 1a A schematic block diagram of an automated test apparatus for providing device-specific communications to a device under test according to an embodiment of the present invention is shown.

[0059] Figure 1b A schematic block diagram of an automated test apparatus for providing device-specific communications to a device under test according to an embodiment of the present invention is shown.

[0060] Figure 2 shows a schematic block diagram of an automated test apparatus for providing device-specific communication to a device under test according to an embodiment of the present invention;

[0061] Figure 3 shows a schematic block diagram of a channel processing unit according to an embodiment of the present invention;

[0062] Figure 4 shows a schematic block diagram of a sandbox in a channel processing unit according to an embodiment of the present invention;

[0063] Figure 5 shows a schematic block diagram of a channel processing unit including a security module according to an embodiment of the present invention;

[0064] Figure 6 shows a schematic block diagram of an automated testing device for document management according to an embodiment of the present invention;

[0065] Figure 7 shows a schematic block diagram of a channel processing unit including a protocol implementation unit according to an embodiment of the present invention;

[0066] Figure 8 shows a schematic block diagram of a channel processing unit with upstream result data preprocessing according to an embodiment of the present invention;

[0067] Figure 9 shows a schematic block diagram of a sandbox in a channel processing unit according to an embodiment of the present invention;

[0068] Figure 10 shows a schematic block diagram of a traditional automated testing equipment. Detailed Implementation

[0069] 1. According to Figure 1a and Figure 1b Automated testing equipment

[0070] Figure 1aA schematic block diagram of an automated testing device 100 according to an embodiment of the present invention is shown.

[0071] The automated test equipment 100 includes a tester control 110 configured to broadcast and / or specifically upload input data 114a (e.g., DUT stream, or incoming tester command stream, or broadcast data, or shared data, or data equivalent to different DUTs, or common expected result data) and device-specific data 114b to a matching module (e.g., to a channel processing unit).

[0072] The automated test apparatus 100 also includes a channel processing unit 124 configured to use device-specific data 114b to transform input data 114a to obtain device-under-test (DUT) adaptation data 126 for testing the DUT 130. Alternatively or additionally, the automated test apparatus 100 is configured to use device-specific data 114b to process DUT data 128 from the DUT 130 to test or evaluate the DUT 130.

[0073] Therefore, channel processing units can generate device-under-test (DUT) adaptation data in a distributed manner. This helps avoid transmitting different DUT adaptation data to different channel processing units, all of which can be coupled to the tester control. For example, the amount of input data 114a (which may be device-agnostic and may not be adapted to a single DUT) can be significantly larger than device-specific data, which may, for example, be different for each individual DUT. Therefore, in an automated test apparatus that includes multiple channel processing units, only a small amount of device-specific data needs to be sent separately to different channel processing units. Furthermore, a tester control that can, for example, use different channel processing units to handle the simultaneous testing of multiple DUTs no longer needs to perform DUT-specific (DUT-individual) adaptation of the "input data," as this function is taken over by one or more channel processing units coupled to the tester control.

[0074] In addition, it should be noted that Figure 1a The automated test equipment may optionally be supplemented by any of the features, functions and details disclosed herein, either individually or in combination.

[0075] Figure 1b A schematic block diagram of an automated testing device 100 according to an embodiment of the present invention is shown.

[0076] The automated test equipment 100 includes a tester control 110. The tester control 110 includes a centralized test process management 112, configured to broadcast and / or specifically upload input data 114a to one or more matching modules (e.g., to matching channel processing units 124a to 124z). Furthermore, the centralized test process management is configured to broadcast and / or specifically upload device-specific data 114b (e.g., keys, and / or certificates, and / or IDs, and / or configurations) to one or more matching modules (e.g., to matching channel processing units 124a to 124z).

[0077] The automated test apparatus 100 also includes a tester 120. The tester includes a tester data bus 122 coupled to a centralized test process management 112 (which is part of the tester control 110) and multiple channel processing units 124a to 124z. The tester data bus 122 is configured to receive (or obtain) input data 114a having device-specific data 114b from the centralized test process management 112 (which is part of the tester control 110) and transmit the input data 114a to one or more of the channel processing units 124a to 124z. The channel processing unit 124a includes a memory unit 124a-1 and a computing unit 124a-2. The device-specific data 114b is stored in the memory unit 124a-1. The input data 114a is processed with the device-specific data 114b in the computing unit 124a-2 to obtain device-under-test (DUT) adaptation data 126 for testing the device under test (DUT) 130a-1.

[0078] The channel processing unit 124a is configured to send device-under-test (DUT) adapter data to the DUT 130a-1 mounted on the load board or probe card 130. The DUT adapter data is transmitted to the corresponding DUT 130a-1 via a device-specific channel 1.1 and the corresponding DUT interface. For example, the DUT interface may be coupled to a PCIe physical interface or a USB physical interface, but may also include a JTAG interface, an iJTAG interface, or any other suitable interface.

[0079] The device-under-test (DUT) adapter data can represent the program code of a test procedure (e.g., for testing a system-on-a-chip) and / or the data to be processed, and can be used on the DUT 130a-1 (e.g., executed or processed). After test execution, the DUT data 128 is transmitted to the channel processing unit 124a via the corresponding DUT interface and device-specific channel 1.1. The channel processing unit 124a is configured to process the corresponding DUT data using device-specific data, for example, to extract upstream result data (e.g., corresponding result data, or DUT data from the DUT). Therefore, the channel processing unit 124a is configured to store the upstream result data in a memory unit and / or analyze the upstream result data using expected result data, or compare it with expected result data. In other words, the analysis of the upstream result data is to indicate whether there is a difference between the upstream result data and the expected result data, where such difference may reflect manufacturing defects on the corresponding DUT. In addition, upstream result data can be preprocessed and / or compressed and / or transmitted (forwarded) to the tester control 110 by the channel processing unit 124a via the tester data bus (interface) 122.

[0080] In multi-site DUT testing, improving testing efficiency is a key enabling factor. Reducing bus traffic and CPU requirements through efficient testing methods can help reduce overall cost and testing time. If there are no software or hardware-related defects or faults on the DUT platform, tests applied to multiple DUTs can yield the same or similar results. Considering this, in the channel processing unit of this invention, a comparison operation can be applied in the calculation unit. Therefore, in the calculation unit, common expected result data from the tester control is compared with corresponding test result data from the DUT. After the comparison operation, only the differences between the common expected test result data and the corresponding test result data can be compressed and transmitted to the tester control 110. This reduces bus traffic and CPU requirements on the tester control.

[0081] Another (optional) feature that contributes to DUT testing efficiency is an optional sandbox, which provides better utilization of memory (124a-1 to 124z-1) and computation (124a-2 to 124z-2) resources. Channel processing units 124a to 124z may optionally include one or more sandboxes (e.g., as shown by reference numeral 124z-3), wherein one or more sandboxes 124z-3 are configured to utilize the capabilities of virtual, separate memory 124z-1 and computation 124z-2 to execute commands (with or without resource sharing, depending on the architecture). One or more sandboxes 124z-3 are configured to transform input data 114a using device-specific data 114b, and / or one or more sandboxes 124z-3 are configured to analyze results received from the DUT 130, which has separate computation capabilities. Furthermore, the automated test equipment 100 is configured to upload software to one or more sandboxes 124z-3 to allow device-specific processing of input data 114a or DUT data 128 using the sandboxes 124z-3. Therefore, the sandbox feature enables virtual, separate memory and computing power to test the DUT 130a-1 in an isolated environment.

[0082] As an additional note, it should be observed that, optionally, two or more devices under test (e.g., DUTs 130a-1 and 130a-2) may be coupled to a single channel processing unit (e.g., coupled to channel processing unit 124a) for example, by using separate channels (e.g., channels 1.1 and 1.2 as shown in Figure 2). However, in some embodiments, a single DUT may be coupled to a single channel processing unit. Furthermore, there may be situations where multiple channel processing units are used to test a single DUT, for example, if the DUT comprises a very large number of pins and / or consists of multiple potentially independent interfaces.

[0083] However, it should also be noted that the tester 120 does not necessarily need to have component 124z. Instead, one or more of the components may be omitted or changed.

[0084] Furthermore, it should be noted that the automated test equipment 100 may optionally be supplemented by any of the features, functions and details disclosed herein, either individually or in combination.

[0085] 2. Based on the example in Figure 2

[0086] Figure 2 shows a schematic block diagram of an automated test apparatus 200 for providing device-specific communication to a device under test 230a-1 according to an embodiment of the present invention.

[0087] The automated test equipment 200 includes a tester control 210. The tester control 210 includes a centralized test process management 212, which is configured to broadcast and / or specifically upload input data (e.g., data 114a) and device-specific data (e.g., data 114b) to one or more matching modules.

[0088] The automated test apparatus 100 also includes a tester 220. The tester includes a tester data bus 222 coupled to a centralized test process management system 212 and multiple channel processing units 224a to 224m. The tester data bus 222 is configured to receive input data containing device-specific data from the centralized test process management system 212 and transmit the input data to the multiple channel processing units 224a to 224m. The channel processing unit 224a includes a memory unit 224a-1 and a computing unit 224a-2. Device-specific data is stored in the memory unit 224a-1. The input data is processed with the device-specific data in the computing unit 224a-2 to obtain device-under-test (DUT) adaptation data 126 for testing the device under test (DUT) 230a-1.

[0089] Each channel processing unit utilizes (local) device-specific data (e.g., local device-specific information and / or keys and / or certificates and / or IDs and / or configurations) to transform input data. Encrypted / decrypted device-specific communication is used to prevent unauthorized access to the internal device structure by interfaces (e.g., Channel 1.1 and Channel 1.2).

[0090] Furthermore, it should be noted that the automated test equipment 200 may optionally be supplemented by any of the features, functions and details disclosed herein, either individually or in combination.

[0091] 3. Based on the example in Figure 3

[0092] Figure 3 shows a schematic block diagram of a channel processing unit 320 according to an embodiment of the present invention. The channel processing unit 320 may, for example, replace channel processing units 124a to 124z or channel processing units 224a to 224m.

[0093] The channel processing unit 320 includes a memory 320a and a computing unit 320b. The memory 320a unit is configured to store data (e.g., device-specific data, which may include, for example, keys and / or certificates and / or IDs) and configurations. The channel processing unit 320 is configured to convert input data (e.g., DUT streams or incoming tester command streams or broadcast data or shared data or data equivalent to different DUTs or common expected result data) into device-specific data or device-specific communication, for example, by using secure device communication or secure device communication encoding and protocol awareness (or protocol awareness encoding) with local device-specific information. Secure device communication is achieved by encrypting or decrypting DUT communication or by authorization or authentication, where authorization refers to granting a certain level of access permission, and authentication refers to verifying the user's identity.

[0094] Furthermore, regarding communication between the DUT and the channel processing unit, communication can be further protected (alternatively or additionally) by using packet counters and / or error correction codes and / or error identification codes.

[0095] For example, by transforming input data sent from the tester control with local device-specific information, protocol-aware data (e.g., device-under-test adaptation data, or data adapted to a single device under test, or expected result data adapted to the device under test) can be obtained.

[0096] Therefore, the channel processing unit 320 can help reduce the load on the tester controls and the tester data bus while ensuring a high level of security.

[0097] Furthermore, it should be noted that the channel processing unit 300 may optionally be supplemented by any features, functions and details disclosed herein, either individually or in combination.

[0098] 4. Based on the example in Figure 4

[0099] Figure 4 shows a schematic block diagram of a sandbox in a channel processing unit according to an embodiment of the present invention.

[0100] The channel processing unit 420 (e.g., which may replace any channel processing unit disclosed herein) may optionally include at least one sandbox 420c, wherein the at least one sandbox 420c includes (or is associated with) a memory 420a and a computing 420b unit.

[0101] The at least one sandbox 420c is configured to transform input data using device-specific data, and / or the at least one sandbox 420c is configured to analyze results received from a DUT 430 with its own computing capabilities. Furthermore, the automated test equipment 400 is configured to upload software to the at least one sandbox 420c to allow device-specific processing of the input data or DUT data using the sandbox 420c. Additionally, the sandbox may include a secure and well-defined interface to the rest of the channel processing unit to allow data to be supplied from the sandbox to the DUT and vice versa. Therefore, the sandbox feature enables the testing of the DUT 430 in an isolated environment using virtual, separate memory and computing power.

[0102] Furthermore, it should be noted that the channel processing unit 400 may optionally be supplemented by any features, functions and details disclosed herein, either individually or in combination.

[0103] 5. Based on the example in Figure 5

[0104] Figure 5 shows a schematic block diagram of a channel processing unit including a security module according to an embodiment of the present invention.

[0105] The channel processing unit 520 (e.g., may replace any channel processing unit disclosed herein) includes a memory 520a and a computing unit 520b. The computing unit 520b also includes a security module 520c. Prior to DUT communication, device-specific data (e.g., keys, certificates, IDs, and configurations) is stored in the local memory 520a. The computing unit 520b, including the security module 520c, is configured to interact with the DUT interface.

[0106] The security module is configured to protect DUT communication by managing and executing encryption / decryption or authorization / authentication functions. Furthermore, communication between the DUT and the channel processing unit can be further protected, for example, by using a packet counter and / or error correction codes and / or error identification codes, to detect errors related to the communication channel (e.g., the transmission medium) after the channel processing unit receives DUT data. Error identification and error correction codes add redundancy to the input data, enabling the checking of the consistency of transmitted data (e.g., DUT adapter data) and recovery of received data if corrupted due to channel transmission. Error identification (detection) codes may, for example, be (or include) cyclic redundancy check (CRC). Error correction codes may typically be (or include), for example, one or more forward error correction codes (e.g., Viterbi decoding, block codes) and / or automatic repeat requests.

[0107] Furthermore, it should be noted that the channel processing unit 500 may optionally be supplemented by any features, functions and details disclosed herein, either individually or in combination.

[0108] 6. Based on the example in Figure 6

[0109] Figure 6 shows a schematic block diagram of an automated testing device 600 for certificate management according to an embodiment of the present invention.

[0110] Tester control 610 includes centralized test process management 612, and centralized test process management 612 also includes a security certificate unit 614. The tester control is configured to acquire (e.g., receive or generate) security certificates and / or keys (e.g., security certificates or keys specific to automated test equipment 600, such as the public key of automated test equipment 600) and broadcast and / or specifically upload (e.g., security certificates or keys) to one or more matching modules (e.g., to channel processing units 524a to 624m, which may, for example, correspond to any channel processing unit disclosed herein) and / or one or more DUTs. Furthermore, encryption can be applied by (or using) a tester-specific certificate known to the CPU.

[0111] Furthermore, it should be noted that the automated test equipment 600 may optionally be supplemented by any of the features, functions and details disclosed herein, either individually or in combination.

[0112] 7. Based on the example in Figure 7

[0113] Figure 7 shows a schematic block diagram of a channel processing unit including a protocol implementation unit according to an embodiment of the present invention.

[0114] The channel processing unit 720 (which may replace any channel processing unit disclosed herein) includes a memory 720a and a computing unit 720b. The computing unit 720b also includes a protocol implementation unit 720c. The protocol for communicating with the corresponding DUT can be programmed in hardware or software and therefore reconfigurable. The computing unit 720b is configured to interact with one or more DUT interfaces.

[0115] The communication protocol implementation in the channel processing unit 720 may be configured, for example, to use (consider) one or more packet counters, and / or handshakes with device-specific content (e.g., device ID), and / or synchronous communication including timestamps, and / or implementations of communication standards such as IEEE 1687.x, or IEEE 1500, or IEEE 1149.x.

[0116] By using a protocol implementation in the computing unit 720b, the amount of data uploaded from the tester control to the channel processing unit can be kept small, as the protocol overhead can be generated by the channel processing unit. Furthermore, the introduction of a device-specific protocol on the channel processing unit side further significantly reduces the load on the tester bus.

[0117] Furthermore, it should be noted that the channel processing unit 700 may optionally be supplemented by any features, functions and details disclosed herein, either individually or in combination.

[0118] 8. Application

[0119] Below, some applications will be described with reference to Figures 8 and 9.

[0120] Figure 8 shows a schematic block diagram of the first case, in which the local preprocessing results of the upstream results are stored and compared with the expected results.

[0121] The channel processing unit 820 (which may replace any channel processing unit disclosed herein) includes a memory 820a and a computing unit 820b. The memory unit 820a includes an expected result unit or memory portion 820a-1, which can store common expected result data provided by the tester controls (which may be common data from multiple devices under test). Furthermore, the computing unit 820b includes a comparator unit 820b-1, which can compare received DUT data (or pre-processed DUT data, pre-processed in a device-specific or device-individual manner, such as using device-specific data) with expected result data (e.g., expected result data processed in a device-specific manner by the channel processing unit using device-specific data), which can be stored in the memory unit 820a.

[0122] The channel processing unit 820 is configured, for example, to process (or preprocess) the corresponding DUT data using device-specific data to extract upstream result data (e.g., corresponding result data, or DUT data from the device under test). Therefore, the channel processing unit 820 is configured, for example, to store the upstream result data in the memory unit 820a. Furthermore, the channel processing unit 820 is configured, for example, to analyze the upstream result data using expected result data. This can be achieved in the comparator unit 820b-1 (part of the calculation unit 820b) by comparing the upstream result data with the expected result data stored in the expected result unit 820a-1 (part of the memory unit 820a).

[0123] Furthermore, upstream result data can be preprocessed and / or compressed and / or transmitted (forwarded) to the tester control, for example, by the channel processing unit via the tester data bus (interface) 822. Upstream result data can be compressed, for example, to reduce the amount of data used for rapid data exchange and to reduce transmission time.

[0124] The automated test equipment 800 is configured, for example, to control the testing of the device under test (DUT) based on the overall test execution program in the test sequence (e.g., uploading of the program, and / or execution of one or more parts of the test program, and / or downloading of result data, and / or debugging). The channel processing unit 820 is configured, for example, to provide output to the sequence of control sequence execution (e.g., timing adjustment of the edges in the signals provided to the DUT), and to transmit a digital data stream or signal sequence with specific timing adjustments to the driver.

[0125] The driver is configured to receive input from a sequence and communicate with the device under test (DUT) via an interface (e.g., an interactive interface, such as an iJTAG, RSN, or IEEE-1687 interface). For example, the driver can be configured to add or adjust analog voltage levels, or it can act as a multiplexer to switch the DUT between different voltage levels, thereby checking the voltage levels that the driver under test can tolerate.

[0126] A driver excites a sequence, which is then transmitted via a data communication channel and communicates with the device under test (DUT) through the DUT interface. For example, the functionality of the DUT at various voltage and frequency levels can be checked using the sequence excited by the driver. In some cases, the sequence received from the DUT and the sequence sent by the DUT must be exactly the same bit-by-bit. For example, the DUT driver can send a data sequence to an automated test equipment 800 via a DfT interface, which checks the received sequence for errors. It should be noted that the channel processing unit is configured, for example, to compare the received sequence (DUT data) with the expected result in a comparator, which is part of the computation unit.

[0127] Generally, different approaches are possible. As an example, the channel processing unit can receive common expected result data from the tester control, convert the common expected result data into device-adapted expected result data, store the device-adapted expected result data, and compare the device-adapted expected result data with the DUT data received from the DUT to evaluate the DUT. Alternatively, the channel processing unit can store common expected result data (which is common to multiple DUTs), extract result data from the DUT data using device-specific data (thus taking into account the device's individual protocol characteristics), and compare the extracted result data with the common result data to evaluate the DUT. However, different processing operations are also possible.

[0128] Figure 9 shows a schematic block diagram of a second scenario, in which a sandbox channel processing unit 920 according to an embodiment of the present invention is shown.

[0129] The channel processing unit 920 includes at least one sandbox 920c, wherein the sandbox 920c includes a memory unit 920a and a computing unit 920b. The memory unit 920a is configured to store device-specific data and configurations.

[0130] The automated test equipment 900 is configured to upload software to at least one sandbox 920c to allow device-specific processing of input or DUT data using the sandbox 920c. Similarly, device-specific functions can be updated by uploading from third-party software to enable efficient device-specific computational steps (e.g., communication with a specific DUT interface that knows the device configuration).

[0131] The sandbox channel processing unit 920 is configured to provide output to a sequencer that controls sequence execution and transmits a signal sequence with specific timing adjustments to a driver. The driver is configured to acquire a digital sequence of signals, add or adjust analog voltage levels, and transmit the signals to the device under test (DUT) 930a via a DUT interface. For example, the functionality of the DUT at various voltage and frequency levels can be checked using a sequence excited by the driver. For example, the DUT driver can send a sequence to a debug interface via a DfT interface. The debug interface can, for example, download a sequence of DUT data and transmit it to an automated test apparatus 900 to check for errors in the received sequence.

[0132] However, it should be noted that the automated test equipment 800, 900 may optionally be supplemented by any of the features, functions and details disclosed herein, either individually or in combination.

[0133] 9. Traditional solution based on Figure 10

[0134] Figure 10 shows a schematic block diagram of a conventional automated test setup 1000. However, it should be noted that, apart from lacking a DUT-specific (or device-specific) channel processing unit and security features such as encryption / decryption, error detection mechanisms, error correction mechanisms, or authentication mechanisms, the conventional automated test setup 1000 is similar to automated test setups 100, 200, or 600. In contrast, existing solutions rely on a centralized channel architecture that cannot perform local data conversion. Furthermore, with a centralized channel architecture, data needs to be transmitted to a central processing unit (CPU) for computation. In this case, high communication overhead or bottlenecks occur for device-specific communication due to CPU operations.

[0135] 10. Conclusion

[0136] Some conclusions will be provided below. Furthermore, various aspects of the invention will be disclosed, which may be used alone or in combination, and may optionally be introduced alone or in combination into any other embodiment.

[0137] According to embodiments of the present invention, efficient and secure device-specific communication is created in multi-site DUT testing.

[0138] According to one aspect of the invention, each channel processing unit is used to transform the central data stream using local device-specific (or local device-specific data).

[0139] According to one aspect, encrypted and device-specific communication can be performed in this way.

[0140] According to another aspect, communication with the channel processing unit (or multiple channel processing units) is as device-agnostic as possible (e.g., in a sense, in the amount of main data communicated between the tester control and the channel processing unit, the characteristics of the individual device under test, such as individual encryption keys or individual certificates, are not taken into account).

[0141] For example, the automated testing equipment shown in Figure 2 can be used for this purpose.

[0142] The following section will describe some aspects related to the channel processing unit.

[0143] According to one aspect, the channel processing unit can convert the incoming tester command stream into device-specific communication, such as security device communication and / or protocol awareness with local device-specific information.

[0144] According to one aspect, the central processing unit can use transparent input / output streams from external workstations (e.g., it can implement tester controls).

[0145] According to one aspect, embodiments of the invention allow (or perform) result analysis directly on the channel processing unit to reduce bus traffic and / or CPU requirements.

[0146] According to one aspect, the channel processing unit combines storage (e.g., memory) and computation (e.g., CPU and / or ASIC and / or FPGA).

[0147] For example, the channel processing unit according to Figure 3 can be used to implement these aspects.

[0148] According to one aspect, the channel processing unit can use a sandbox.

[0149] For example, a sandbox may include the ability to execute tester commands locally using its individual memory and computing power (with or without resource sharing, depending on the architecture).

[0150] According to one aspect, the sandboxes communicate with the host channel processing unit using protected interfaces, thus isolating one sandbox from another. In some embodiments, inter-sandbox communication is only possible if specifically permitted (e.g., using configuration).

[0151] Depending on one aspect, each channel can have one or more sandboxes.

[0152] Figure 4 shows an example of a channel processing unit using one or more sandboxes.

[0153] Applications of various aspects of the present invention will be described below.

[0154] According to one aspect, embodiments of the invention can be used to perform secure device communication.

[0155] According to one aspect, device-specific data (e.g., keys, certificates, IDs, configurations) is stored in local memory before communication.

[0156] On the other hand, the computing module interacts with the DUT interface, for example, to implement communication protection (e.g., using encryption and / or decryption and / or using packet counters and / or using error correction and error identification codes, etc.).

[0157] According to one aspect, communication protocols can be implemented in hardware or in software.

[0158] Figure 5 shows an example of a channel processing unit that uses secure devices for communication.

[0159] According to one aspect, security device communication includes certificate management.

[0160] For example, in the first step, a certificate (device-specific or device-specific) is presented to the test process management.

[0161] Furthermore, for example, in the second step, there is an upload to the channel processing unit, which can be performed using broadcast or by using a specific ground upload to the matching module.

[0162] Furthermore, according to one aspect, there may be encryption (e.g., certificate encryption) performed by a tester-specific certificate known to the CPU (e.g., the CPU of the tester control and the CPU of the channel processing unit).

[0163] Figure 6 shows an example of an automated testing device using certificate management.

[0164] According to one aspect, embodiments of the invention are adapted for performing secure multi-site protocol awareness tests.

[0165] According to one aspect of the invention, the protocol implementation on the channel processing unit may be, for example:

[0166] Group counter, and / or

[0167] Handshake with device-specific content, such as ID, and / or

[0168] Highly efficient non-multi-site synchronization protocol-aware communication (e.g., using local processing of device-specific parts), and / or

[0169] Implementation of communication standards (such as IEEE 1687.x, IEEE 1500, IEEE 1149.4).

[0170] Figure 7 shows an example of a channel processing unit used for secure multi-standard protocol awareness testing.

[0171] According to one aspect, embodiments of the invention utilize local preprocessing of upstream results.

[0172] According to one aspect, the expected result is stored on the channel processing unit (e.g., in the first step).

[0173] According to one aspect, during test execution, upstream result data is analyzed and preprocessed (e.g., using signature generation and / or using test result compression) before being transmitted on the tester bus interface.

[0174] This allows for efficient, interactive test stream execution across multiple sites.

[0175] Figure 8 shows an example of a channel processing unit (or test chain) that uses the upstream results for local preprocessing.

[0176] On the other hand, customers can upload their code to a sandbox.

[0177] In one respect, device-specific functions can be executed directly on the sandbox channel processing unit as specified by the customer. This enables efficient device-specific computational steps. For example, it allows communication with a specific DfT (Design for Testability) interface that knows the device configuration. Furthermore, this allows for efficient, interactive test flows across multiple sites.

[0178] Figure 9 shows an example of a channel processing unit (or test chain).

[0179] The advantages of embodiments of the present invention compared to conventional solutions will be discussed below. However, it should be noted that embodiments of the present invention do not necessarily include some or all of the advantages mentioned below.

[0180] According to embodiments of the present invention, a DUT-specific (device-specific) channel processing unit as part of an automated test apparatus is disclosed. In other words, embodiments of the present invention address the problem of reduced communication overhead by introducing DUT-specific communication. For example, in standard methods, multiple DUTs being tested in parallel construct a complete processing load in a central processing unit. DUT-specific processing, however, is performed in the corresponding channel processing unit, improving communication overhead on the interface (or data bus).

[0181] Embodiments of the present invention are based on secure communication methods to achieve secure multi-site DUT testing using an advanced security architecture. The security mechanisms rely on encrypted / decrypted DUT communication, or error detection / correction, or authentication mechanisms. Furthermore, communication between the DUT and the channel processing unit is further protected, for example, by using packet counters and / or error correction codes and / or error identification codes. This ensures the highest possible security in a multi-site testing environment.

[0182] Furthermore, embodiments of the invention allow for efficient device-specific communication. Specifically, this is achieved through a result analysis method and a sandbox channel processing unit method. For example, in the result analysis method, corresponding test result data from the DUT is compared with commonly expected result data broadcast by the tester control in the channel processing unit. In cases where the corresponding test result (upstream result data) differs from the commonly expected result data, the difference between the corresponding test result data and / or the commonly expected test result data and the corresponding test result data is compressed and transmitted to the tester control. In summary, the result analysis method on the channel processing unit minimizes test time by reducing bus traffic and CPU requirements. In some embodiments, a sandbox channel processing unit is used, where device-specific functions can be updated by uploading from third-party software to enable efficient device-specific computational steps. For example, customized DUT tests can be performed from a third party.

[0183] In summary, embodiments of the present invention can be used to test the device under test in an efficient and safe manner, and are therefore superior to other concepts.

[0184] 11. Implement alternative solutions

[0185] It should be noted that the memory described herein (and shown in the accompanying drawings) can be implemented, for example, as volatile (e.g., using RAM, DDR, embedded memory, etc.) and / or non-volatile (e.g., using SSD, HDD, flash memory, etc.).

[0186] Although some aspects have been described in the context of the apparatus, it is clear that these aspects also represent a description of the corresponding method, where a block or device corresponds to a method step or feature of a method step. Similarly, aspects described in the context of method steps also represent a description of a corresponding block or item or feature of the corresponding apparatus. Some or all of the method steps can be performed by (or using) hardware devices, such as microprocessors, programmable computers, or electronic circuits. In some embodiments, one or more of the most important method steps can be performed by such devices.

[0187] Depending on certain implementation requirements, embodiments of the present invention can be implemented in hardware or software. This implementation can be performed using a digital storage medium (e.g., floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM, or flash memory) that stores electronically readable control signals thereon, which cooperates (or is capable of cooperating with) a programmable computer system to perform the corresponding methods. Therefore, the digital storage medium can be computer-readable.

[0188] Some embodiments of the invention include a data carrier having electronically readable control signals, which is capable of cooperating with a programmable computer system to perform one of the methods described herein.

[0189] Typically, embodiments of the present invention can be implemented as a computer program product having program code that, when run on a computer, is operable to perform one of the methods. The program code may, for example, be stored on a machine-readable medium.

[0190] Other embodiments include a computer program stored on a machine-readable medium for performing one of the methods described herein.

[0191] In other words, therefore, one embodiment of the method of the present invention is a computer program having program code that, when the computer program is run on a computer, performs one of the methods described herein.

[0192] Therefore, another embodiment of the method of the present invention is a data carrier (or digital storage medium, or computer-readable medium) comprising a computer program recorded thereon for performing one of the methods described herein. Data carriers, digital storage media, or recording media are generally tangible and / or non-transferable.

[0193] Therefore, another embodiment of the method of the present invention is a data stream or signal sequence representing a computer program for performing one of the methods described herein. The data stream or signal sequence may, for example, be configured to be transmitted via a data communication connection (e.g., via the Internet).

[0194] Another embodiment includes a processing device, such as a computer or programmable logic device, configured or adapted to perform one of the methods described herein.

[0195] Another embodiment includes a computer having a computer program installed thereon for performing one of the methods described herein.

[0196] Another embodiment of the invention includes an apparatus or system configured to transmit (e.g., electronically or optically) a computer program for performing one of the methods described herein to a receiver. For example, the receiver may be a computer, a mobile device, a memory device, etc. The apparatus or system may, for example, include a file server for transmitting the computer program to the receiver.

[0197] In some embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. In some embodiments, the field-programmable gate array may cooperate with a microprocessor to perform one of the methods described herein. Generally, these methods are preferably performed by any hardware device.

[0198] The apparatus described herein can be implemented using hardware devices, a computer, or a combination of hardware devices and a computer.

[0199] The apparatus described herein, or any component thereof, may be implemented, at least in part, in hardware and / or software.

[0200] The methods described herein can be performed using hardware devices, computers, or a combination of hardware devices and computers.

[0201] The methods or any components of the apparatus described herein may be performed, at least in part, by hardware and / or software.

[0202] The above embodiments are merely illustrative of the principles of the invention. It should be understood that modifications and variations to the arrangements and details described herein will be apparent to those skilled in the art. Therefore, this document is intended to be limited only by the scope of the appended patent claims, and not by the specific details presented through the description and interpretation of the embodiments herein.

Claims

1. A device for testing one or more devices under test (130a-1 to 130z-n; 230a-1 to 230m-1; 330a to 330m; 430; 530a to 530m; 630a-1 to 630m-n; 730a, 730b; 830a, 830b); Automated testing equipment (100) for 930a and 930b 200), the automated testing equipment includes: Tester controls (110; 210; 610) are configured to output input data and device-specific data, wherein the input data is unknown to the one or more devices under test, the device-specific data is specific to the corresponding device under test among the one or more devices under test, and the device-specific data includes keys and / or certificates and / or IDs and / or configuration information, and the amount of input data is greater than the amount of device-specific data; Channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) are coupled to the tester control. The channel processing unit is configured to receive the input data and the device-specific data from the tester control, encrypt the input data using the device-specific data or implement a communication protocol to obtain device-under-test (DUT) adaptation data for testing the corresponding DUT, and / or The channel processing unit is configured to receive corresponding DUT data from the one or more devices under test, and to encrypt, decrypt, implement communication protocols, or unpack protocol information from the corresponding device under test using device-specific data specific to the corresponding device under test, in order to test the corresponding device under test.

2. The automated testing equipment according to claim 1, in, The channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) are configured to communicate with one or more DUTs (130a-1 to 130z-n; 230a-1 to 230m-1; 330a to 330m430, 530a to 530m; 630a-1 to 630m-n; 730a, 730b; 830a, 830b; 930a, 930b) via device-specific channels. This allows the device under test (DUT) to transmit its adapter data to the DUT and / or receive the DUT data from the DUT.

3. The automated testing equipment according to any one of claims 1 to 2, in, The channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) are configured to communicate with the tester controls (110; 210; 610) using the tester interface (122; 222; 322; 422; 522; 622; 722; 822; 922).

4. The automated testing equipment according to claim 3, in, The tester controls (110; 210; 610) are configured to broadcast input data to multiple channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) via the tester interfaces (122; 222; 324a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920).

5. The automated testing equipment according to claim 3, in, The tester interface (122; 222; 322; 422; 522; 622; 722; 822; 922) is the tester data bus, which is coupled to the tester control (110; 210; 610) and multiple channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920).

6. The automated testing equipment according to claim 1, in, The channel processing unit (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) includes volatile or non-volatile storage devices (224a-1 to 224m-1; 320a; 420a; 520a; 624a-1 to 624m-1; 720a; 820a; 920a) and computing units (124a-2 to 124z-2; 224a-2 to 224m-1; 320b; 420b; 520b; 624a-2 to 624m-2; 720b; 820b; 920b), and The channel processing unit is configured to store device-specific data in its storage device, and The channel processing unit is configured to use the computing unit to transform the input data and / or use the computing unit to process the DUT data.

7. The automated testing equipment according to claim 1, in, The channel processing unit (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) includes one or more sandboxes (920c). The one or more sandboxes are configured to execute commands using separate memory, and / or Wherein, the one or more sandboxes are configured to use device-specific data to transform the input data, and / or The one or more sandboxes are configured to analyze the results received from the DUT.

8. The automated testing equipment according to claim 1, in, The channel processing unit (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) includes multiple sandboxes (920c). The sandboxes are configured to communicate with the host channel processing unit (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) using one or more protected interfaces, thereby isolating the different sandboxes from each other.

9. The automated testing equipment according to claim 1, in, The channel processing unit (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) includes one or more sandboxes (930), wherein the one or more sandboxes are configured to perform device-specific functions using the device-specific data.

10. The automated testing equipment according to claim 7, in, The automated test equipment is configured to upload software to one or more sandboxes (930) to allow device-specific processing of the input data or the DUT data using the sandboxes.

11. The automated testing equipment according to claim 1, in, The channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) are configured to use device-specific data to implement a communication protocol to protect communication between the channel processing units and the device under test.

12. The automated testing equipment according to claim 1, in, The channel processing unit (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) includes a computing unit (124a-2 to 124z-2; 224a-2 to 224m-1; 320b; 420b; 520b; 624a-2 to 624m-2; 720b; 820b; 920b). The computing unit is configured to interact with one or more DUT interfaces, and The computing unit is configured to encrypt the input data to obtain the device under test (DUT) adaptation data, and / or decrypt the DUT data, and / or perform error detection on the DUT data, and / or perform error correction on the DUT data, and / or implement a communication protocol using one or more packet counters to obtain the DUT adaptation data or evaluate the DUT data, and / or implement a communication protocol using one or more device-specific identifiers to obtain the DUT adaptation data or evaluate the DUT data.

13. The automated testing equipment according to claim 1, in, The channel processing unit (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) includes a computing unit (124a-2 to 124z-2; 224a-2 to 224m-1; 320b; 420b; 520b; 624a-2 to 624m-2; 720b; 820b; 920b). The computing unit is configured to implement the communication protocol in hardware and / or software.

14. The automated testing equipment according to claim 1, in, The tester controls (110; 210; 610) are configured to obtain security certificates and / or keys, and The tester control is configured to broadcast the security certificate and / or key to one or more channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920), and / or specifically upload the security certificate and / or key to a matching channel processing unit.

15. The automated testing equipment according to claim 1, in, The tester controls (110; 210; 610) are configured to obtain a security certificate and / or broadcast it to one or more DUTs.

16. The automated testing equipment according to claim 1, in, The implementation of the communication protocol in the channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) is configured to use one or more of the following: • One or more group counters; • Handshake with device-specific content; • Synchronous communication; • Implementation of communication standards.

17. The automated testing equipment according to claim 1, in, The channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) are configured to store upstream results and / or analyze upstream result data, and / or preprocess the upstream result data, and / or transmit preprocessed and / or compressed upstream result data to the tester controls (1102; 210; 610).

18. The automated testing equipment according to claim 1, in, The automated testing equipment includes multiple channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920). The tester controls (110; 210; 610) are configured to provide common data to the plurality of channel processing units. Different channel processing units are configured to use different device-specific data to convert the common data into different device-under-test (DUT) adaptation data, and to use the different DUT adaptation data to test different DUTs.

19. The automated testing equipment according to claim 1, in, The tester controls (110; 210; 610) are configured to provide common stimulus data to multiple channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920), and The channel processing unit is configured to use device-specific data to transform the common excitation data.

20. The automated testing equipment according to claim 19, in, The channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920) are configured to use device-unique data or device-specific data to transform the common stimulus data to provide device-specific communication.

21. The automated testing equipment according to claim 1, in, The automated testing equipment includes multiple channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920). The tester controls (110; 210; 610) are configured to provide common expected result data to the plurality of channel processing units. Different channel processing units are configured to use the common expected result data to obtain corresponding test results associated with the respective device under test.

22. The automated testing equipment according to claim 1, in, The automated testing equipment includes multiple channel processing units (124a to 124z; 224a to 224m-2; 320; 420; 420; 624a-1 to 624m; 720; 820; 920). The tester controls (110; 210; 610) are configured to provide common expected result data to the plurality of channel processing units. Different channel processing units are configured to extract corresponding result data from the corresponding DUT data using different device-specific data, and compare the corresponding result data with the common expected result data to obtain the corresponding test results associated with the corresponding device under test.

23. A method for testing one or more devices under test in an automated test apparatus, the automated test apparatus including tester controls and a channel processing unit, the method comprising: In the tester control, input data and device-specific data are output. The input data is unknown to the one or more devices under test, and the device-specific data is specific to the corresponding device under test among the one or more devices under test. The device-specific data includes keys and / or certificates and / or IDs and / or configuration information. The amount of input data is greater than the amount of device-specific data. In the channel processing unit, the input data and device-specific data are received from the tester control. The device-specific data is used to encrypt the input data or implement a communication protocol to obtain device-under-test (DUT) adaptation data for testing the corresponding DUT. In the channel processing unit, corresponding DUT data is received from the one or more devices under test, and the DUT data from the corresponding device under test is encrypted, decrypted, or communication protocol or unpacking protocol information is implemented using device-specific data for the corresponding device under test, in order to test the corresponding device under test.

24. A computer-readable storage medium having a computer program stored thereon, the computer program being executed, when run on a computer, for performing the method according to claim 23.

Images