Testing systems and methods with cross-platform bridge components

Abstract

The bridging component is implemented as a computing unit comprising a first communication interface, a second communication interface, and a processor. The computing unit may receive a test program for testing a DUT that is communicably coupled to the computing unit from one or more external systems communicably coupled to the computing unit. Additionally, the computing unit may transmit a command to the DUT to execute the test program, receive test results from the DUT, and transmit the test results to appropriate external system(s). Additionally, for each of a set of one or more DUTs, the computing unit may determine the respective type of each DUT within the set, associate the set with the respective test program, and issue a command to the DUT(s) within the set to execute the respective test program using an operating system compatible with the respective type of each DUT(s) within the set.

Description

Technology Field

[0001] (Related U.S. Application)

[0002] This application is related to U.S. Application No. 18 / 673,796 (Attorney Docket No. AATS-0118-02C01US (24P016US01)), filed on May 24, 2024, and the entirety of which is incorporated herein by reference, titled “Test system and method using cross-platform bridge components” by K. Ranganathan et al. Background Technology

[0003] End-user electronic devices are typically tested to verify their performance and functionality. Devices can be tested using a wide variety of test cases, and the results are compared to expected outputs. If the test results do not match the expected results for the Device Under Test (DUT), the DUT may be classified as a failed device or an outlier, or it may be discarded, for example, based on its performance. By eliminating defective or unsatisfactory devices during the engineering and manufacturing stages, the yield of high-quality devices can be significantly improved.

[0004] The device under test (DUT) may include, but is not limited to, any type of end-user electronic device such as a computer system, a smartphone, or a USB (Universal Serial Bus) connected gadget or a PCIE (Peripheral Component Interconnect Express) connected gadget (e.g., an electronic device designed to perform a task), or the DUT may be a wafer or component intended to be integrated into such a device. The DUT is typically tested by an Automated Test Equipment (ATE) system, which may be used to perform complex tests using software and automation to improve test efficiency.

[0005] A limitation of conventional testing is that tests are performed using test systems (end-device "tester ecosystems" or "vendor ecosystems") specialized according to the type of DUT. Therefore, to test different types of DUTs, it is necessary to modify the tester ecosystem to suit the new DUT. More specifically, different types of DUTs may require distinct hardware and / or software for testing. For example, one type of DUT may require a specific hardware interface (e.g., USB) to communicate with the test system and / or a specific operating system (e.g., Linux®) to execute the test, while another type of DUT may require a different hardware interface (e.g., PCIE or Ethernet) and / or a different operating system (e.g., Windows®). Changing the hardware and / or software required for testing increases the time and cost required to prepare for the test.

[0006] Furthermore, different types of DUTs may have different form factors (e.g., different sizes and / or shapes), which can be problematic in conventional test systems. For instance, DUTs are placed on a Test Interface Board (TIB) for testing, and conventional test systems use TIBs designed to fit specific form factors. Consequently, if DUTs with different form factors are to be introduced into a test system, different TIBs designed to accommodate those different form factors must be swapped out within the test system. This can also increase both the time required for test preparation and the test costs.

[0007] In addition, different types of tests may require different types of hardware-based connections with the DUT. For example, one type of functional test may require one type of connection (e.g., WiFi), while another type of functional test may require Bluetooth®.

[0008] The number and variety of tests (e.g., System Level Tests [SLT], burn-in tests, functional tests, and scan tests), the other factors mentioned above (e.g., various types of DUTs, various hardware interfaces, various operating systems), and the specific requirements of the specialized tester ecosystem necessitate complex bidirectional communication between the test system and the DUT's hardware, "bare metal," and firmware. Furthermore, most of this communication is typically managed by individual, isolated, and discrete software and hardware components, which poses a problem for several reasons. Individual components often lead to difficulties in integration. Ensuring seamless communication between heterogeneous systems can be complex and time-consuming, requiring extensive custom development and ongoing maintenance. When each component operates in isolation, a lack of coordination can lead to inefficiency. For example, repetitive tasks may be executed, or data may need to be transmitted manually between systems, which can slow down the entire test process. Additionally, separated components make it difficult to debug the entire system in functional use cases. Isolated systems can lead to more failure points because data inconsistencies and communication errors are more likely to occur when information is transferred between multiple standalone systems. As test requirements evolve and the number of DUTs increases, it becomes difficult to expand the ecosystem of isolated components. Adapting to changing needs can be challenging, as each new requirement or addition may necessitate additional custom integration work. Furthermore, maintaining multiple standalone systems can be costly. means of solving the problem

[0009] An embodiment according to the present invention overcomes the aforementioned problems and failures by introducing a test system comprising a bridging component that acts as an overall test orchestrator and performs various operations and functions across a plurality of different platforms and a plurality of different types of DUTs (devices under test). Furthermore, an embodiment according to the present invention introduces a test assembly integrating such a bridging component, and a method of using such a bridging component, such a test assembly, and such a test system, or using them together.

[0010] Generally, in an embodiment according to the present invention, the vendor ecosystem (test system) comprises a test assembly including a plurality of power distribution boards (PDBs) and a plurality of test interface boards (TIBs). The PDBs and TIBs may be installed in a test rack. A DUT is connected (e.g., mounted) to one or more TIBs, and the PDB controls the power supply to the TIBs, among other functions further described herein. The end-user electronic device (DUT) that can be tested may be substantially any type of device, such as, but not limited to, a telephone (e.g., a smartphone), a laptop, a tablet, a workstation, a controller (e.g., a game controller), a watch, a central processing unit (CPU), a graphics processing unit (GPU), a sensor, a sensor input board (SIB), and a gadget (e.g., a USB-connected gadget and a PCIE-connected gadget). Additionally, the DUT may be an individual component of such a device.

[0011] An embodiment according to the present invention introduces a "cross-platform bridge" into a vendor ecosystem (test system). The cross-platform bridge connects the client ecosystem with the vendor ecosystem to test devices (e.g., end-user devices of the maximum form factor). The cross-platform bridge enables seamless bidirectional communication between the client ecosystem and the vendor ecosystem and is "hardware independent." The cross-platform bridge acts as a whole orchestrator, performs various functions across multiple platforms, and supports multiple DUT types and scales.

[0012] More specifically, in some embodiments, the cross-platform bridge includes a plurality of computing units (e.g., single-board computers, SBCs) on the PDB. Each computing unit / SBC may be connected to any practical number of DUTs, including different types of DUTs, on one or more TIBs. The cross-platform bridge may determine the type of DUT and its respective location on the TIB. The cross-platform bridge may execute a respective test program on each set of DUTs of the same type using a software platform (e.g., an operating system) compatible with that DUT type, receive test results, and provide the results to the client ecosystem. The test program may include system-level tests, functional tests, and scan tests.

[0013] In some embodiments, the bridging component (cross-platform bridge) is implemented as a computing unit comprising a first communication interface, a second communication interface, and a processor. This computing unit may receive a test program for testing one or more DUTs that are communicably coupled to the computing unit from one or more external systems (e.g., intermediary devices such as a client system or a proxy server) that are communicably coupled to the computing unit. Additionally, the computing unit may transmit a command to the DUT(s) to execute the test program, receive test results from the DUT(s), and transmit the test results to appropriate external systems(s). Furthermore, the computing unit may determine the type of DUT for a set of one or more DUTs, determine the location of the DUT(s) within the test system, associate each test program with the DUT(s), and issue a command to the DUT(s) to execute each test program using an operating system compatible with the type of the DUT(s).

[0014] In some embodiments, the test assembly includes one or more test interface boards and one or more power distribution boards. Each test interface board includes a connection interface. Each of these connection interfaces is configured to be connected to a respective DUT. One or more computing units are coupled to each power distribution board. Each of the one or more computing units is configured to be connected to a respective set of one or more DUTs. Since each of the one or more computing units can function as a cross-platform bridge as described above, it can determine the type of DUT(s) in each set, determine the location of the DUT(s) in each set within the test assembly, select an operating system compatible with the type of DUT(s) in each set, and execute a test program on each DUT in each set using that operating system.

[0015] In some embodiments, the test system includes a test assembly similar to that described above. Additionally, the test system includes an intermediary device (e.g., a proxy server) that provides remote access to the computing unit(s). Each of the one or more computing units is configured to be connected to a set of one or more DUTs associated with a respective client system and can function as a cross-platform bridge as described above. That is, each of the one or more computing units can run a plurality of operating systems, identify the location of each DUT in a set of DUTs on one or more test interface boards, determine the type of DUT(s) in the set, receive a test program from the client system via the intermediary device, execute the test program using an operating system compatible with the type of DUT in the set of DUTs, and transmit the test results to the client system via the intermediary device.

[0016] In addition, embodiments according to the present invention introduce a method (e.g., software) used by or in conjunction with a bridging component, a test assembly, and a test system.

[0017] In a method embodiment, a computing unit (e.g., an SBC) receives a test program from an external system (e.g., an intermediary device such as a client system or a proxy server). The test program is intended to test a DUT that is communicably coupled to the computing unit and one or more TIBs. The TIBs are configured to be connected to different types of devices having different form factors. The computing unit determines the type of DUT(s) and the respective location of each DUT(s) on the respective TIB(s). The computing unit selects an operating system compatible with the type of DUT(s) from among a number of operating systems residing on the computing unit and executable by the computing unit. The computing unit issues a command to execute the test program on each DUT using the selected operating system, and the test program is executed. The computing unit receives the test results and transmits the test results to the external system.

[0018] In a method embodiment, a computing unit detects a connection between one or more test interface boards (e.g., TIBs (131 and 132)) within a test rack and the DUT(s). The DUTs within the test rack may include different types of devices having different form factors. The computing unit accesses a test program associated with a set of one or more DUTs from memory and maps the test program to a location within the test rack of each DUT in the set of DUT(s). Among a number of operating systems residing in the computing unit's memory, an operating system compatible with the type of device in the set of DUT(s) is selected. Then, the test program is executed on each DUT in the set of DUT(s) using this operating system.

[0019] In a method embodiment, a plurality of test programs are received on a computing unit on a power distribution board within a test assembly of a test system. The test programs are intended to test DUTs within one or more test racks of the test system or test assembly. Each test program includes a separate command for testing a set of DUTs. A first test program is mapped to a location within the test assembly of each DUT of a first set of DUTs, and the first set of DUTs is associated with the first test program and uses a first operating system. A second test program is mapped to a location within the test assembly of each DUT of a second set of DUTs, and the second set of DUTs is associated with the second test program and uses a second different operating system. The first test program is executed on each DUT within the first set of DUTs using the first operating system, and the second test program is executed on each DUT within the second set of DUTs using the second operating system. The second test program may be executed simultaneously with the execution of the first test program. In one embodiment, the first test program and the second test program are executed simultaneously by the same computing unit. The results of testing the first set of DUT(s) are transmitted to the first client system, and the results of testing the second set of DUT(s) are transmitted to the second client system.

[0020] Accordingly, an embodiment according to the present invention provides a cross-platform bridge (including a computing unit or a plurality of computing units) that operates as a whole test orchestrator and can perform various functions across a plurality of different platforms and DUT types. Different types of DUTs can be tested without the need to reset the tester ecosystem. Furthermore, bidirectional communication with the DUT hardware, bare metal (e.g., a device or computer system without a basic operating system or application), and firmware is simplified.

[0021] Other advantages provided by embodiments of the present invention include, by but not limited to, the ability to execute various types of tests such as system-level tests (SLT), functional tests, scan tests, stress tests, connectivity tests, digital tests, and debugging operations, which, by but not limited to, include testing for various communication and connectivity technologies and protocols for digital circuits and RF (radio frequency) circuits, such as Internet Protocol (IP), Transmission Control Protocol (TCP), Hypertext Transfer Protocol (HTTP), 4G and 5G cellular, Wi-Fi, Bluetooth, and Near Field Communication (NFC). In some embodiments, the power distribution board connected to the DUT is an individual single-board computing unit that interfaces with each DUT. As such, the disclosed test system provides a fully integrated ecosystem for automating the full execution of any test program directly on the DUT. Slots within the TIB are configurable to support different form factors. Thus, the DUT can be easily replaced and may include any combination of devices with different form factors.

[0022] Other features, purposes, and advantages of embodiments according to the present invention, as illustrated in various drawings, are provided in the detailed description below.

[0023] This description is provided to introduce a selection of concepts that are described in more detail in the detailed description below. This description is not intended to identify the principal or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Brief explanation of the drawing

[0024] The accompanying drawings, incorporated into and forming part of this specification, illustrate embodiments according to the present invention and serve to explain the principles of the present invention disclosed together with the detailed description. In the accompanying drawings, similar reference numerals indicate similar elements. The drawings are not necessarily drawn to actual scale. FIG. 1 is a block diagram showing selected elements of a test system in an embodiment according to the present invention. FIG. 2 is a block diagram showing selected elements of a computing unit in an embodiment according to the present invention. FIG. 3 is a block diagram of an example of a power distribution board in an embodiment according to the present invention. FIG. 4 is a block diagram of an example of a test interface board in an embodiment according to the present invention. FIGS. 5a, 5b, 5b, and 5d are block diagrams showing examples of different test setups in an embodiment according to the present invention. FIG. 6a illustrates an example of a power distribution board and a test interface board in an embodiment according to the present invention. FIG. 6b illustrates an example of selected elements within a test rack in an embodiment according to the present invention. FIG. 7 is a flowchart of an example of a method performed by a computing unit in an embodiment according to the present invention. FIG. 8 is a flowchart of an example of a method performed by a computing unit in a test assembly in an embodiment according to the present invention. FIG. 9 is a flowchart of an example of a method performed by a test system in an embodiment according to the present invention. Specific details for implementing the invention

[0025] Now, various embodiments of the present invention will be described in detail, as examples of the invention are illustrated in the accompanying drawings. While described in relation to these embodiments, it will be understood that these embodiments are not intended to limit the invention to these embodiments. On the contrary, the present disclosure is intended to cover alternatives, modifications, and equivalents that may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, the following detailed description of the invention provides numerous specific details to provide a thorough understanding of the invention. However, it will be understood that the invention may be practiced without these specific details. In other cases, well-known methods, procedures, components, and circuits are not described in detail to avoid unnecessarily obscuring aspects of the invention.

[0026] Some of the detailed descriptions are presented in terms of procedures, steps, logical blocks, processes, and other symbolic representations of operations on data bits that may be performed on computer memory (e.g., FIGS. 7, 8, and 9). These descriptions and representations are the means used by those skilled in the art to convey their work to those skilled in the art most effectively. Procedures, computer execution steps, logical blocks, processes, etc. are considered, in this specification and generally, as steps or instructions of a self-consistent sequence that produce a desired result. A step is one that requires the physical manipulation of a physical quantity. Although not essential, such quantities generally take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated in a computer system or computing unit. Primarily for general use, it is sometimes convenient to refer to such signals as bits, values, elements, symbols, characters, terms, numbers, or parameters.

[0027] However, it should be kept in mind that all such terms and similar terms are to be associated with appropriate physical quantities and are merely convenient labels applied to such quantities. Unless otherwise clearly stated in the description below, descriptions using terms such as “receive,” “determine,” “select,” “store,” “transmit,” “receive,” “download,” “publish,” “execute,” “provide,” “create,” “transmit,” “upload,” “process,” “detect,” “access,” or “mapping” refer to the operations and processes of a computer system or computing unit or a similar electronic computing unit that manipulate and convert data represented by physical (electronic) quantities within the registers and memory of a computer system into other data similarly represented by physical quantities within the computer system memory or registers or other similar information storage, transmission, or display devices. As used herein, the term “communicably coupled” indicates that the respective elements (e.g., devices) may communicate with each other directly and / or indirectly through one or more intermediate elements via wired and / or wireless connections. As used in this specification, the term “connection” refers to a state of being connected to another element (e.g., a device) or a function that can be connected, such as a direct physical connection with another device or a connection that enables communication with another device.

[0028] The embodiments described herein may be described in the general context of computer-executable instructions residing on some form of computer-readable storage medium, such as program modules, which are executed by one or more computing units or other devices. By example, without limitation, computer-readable storage media may include non-transient computer storage media and communication media. Generally, a program module includes routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. The functions of a program module may be combined or distributed as desired in various embodiments.

[0029] Computer storage media include volatile and non-volatile, removable and non-removable media implemented by any information storage method or technology, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, by example but not limiting, random access memory, read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technologies, compact disc ROM (CD-ROM), digital multi-purpose disc (DVD), or other optical or magnetic storage devices or any other media that can be used to store desired information and can be accessed to retrieve said information.

[0030] A communication medium may include computer-executable instructions, data structures, and program modules, and includes any information transmission medium. By example, not limiting, a communication medium includes wired media such as wired networks or direct wired connections, and radio media such as acoustic, radio frequency (RF), infrared, and other radio media. Additionally, any combination thereof may be included within the scope of a computer-readable medium.

[0031] Test system and method using cross-platform bridge components

[0032] Generally, embodiments according to the present invention provide a vendor ecosystem (test system) capable of executing a complete set of different types of tests on different types of devices under test (DUTs). This test system includes a plurality of power distribution boards (PDBs) and a plurality of test interface boards (TIBs). The PDBs and TIBs may be installed in a test rack. The DUT is connected (e.g., mounted) to one or more TIBs, and the PDB controls the power supply to the TIBs among other functions described in more detail below. The DUT may be substantially any type of device and may have various form factors. Additionally, the DUT may be an individual component of such a device.

[0033] An embodiment according to the present invention includes a test system comprising a novel computing unit (also referred to herein as a “cross-platform bridge”) that connects a client ecosystem with a vendor ecosystem to test a device (“device under test”) (e.g., an end-user device of the maximum form factor). The cross-platform bridge may be mounted on a PDB and enables seamless bidirectional communication between the client and the vendor ecosystem and is “hardware independent” (e.g., designed to operate appropriately on various (possibly arbitrary) platforms or devices regardless of the specific hardware used by the platform or device).

[0034] More specifically, in some embodiments, the cross-platform bridge comprises a plurality (one or more) computing units (e.g., single-board computers) that can be connected to any practical number of DUTs, including different types of DUTs on one or more TIBs. The DUTs may be any type of device, such as, but not limited to, telephones (e.g., smartphones), laptops, tablets, workstations, controllers (e.g., game controllers), watches, central processing units (CPUs), graphics processing units (GPUs), sensors, sensor input boards (SIBs), and gadgets (e.g., USB-connected gadgets and PCIE-connected gadgets). Additionally, the DUTs may be individual components of these devices.

[0035] The cross-platform bridge acts as a total orchestrator for test and communication, performing various functions across multiple different platforms, providing execution contexts for tests, providing device isolation, specifying parameters such as voltage and current levels for testing DUT components, and supporting multiple different types of DUTs and various scales (e.g., varying numbers of DUTs). The cross-platform bridge can determine the types of DUTs and their respective locations on TIB(s). The cross-platform bridge can execute individual test programs on each set of DUTs of the same type using a software platform (e.g., an operating system) compatible with that DUT type, receive test results, save results, post-process results, package results from DUTs of the same type, and provide those results to the client ecosystem. The test program may include, for example, system-level tests (SLT), functional tests, scan tests (e.g., via USB [Universal Serial Bus], PCIe [Peripheral Component Interconnect Express], or JTAG [Joint Test Action Group]), stress tests, connectivity tests, digital tests, and debugging operations, which include testing of various communication and connectivity technologies and protocols for digital circuits and RF (radio frequency) circuits (examples, but not limited to, IP, TCP, HTTP, 4G and 5G cellular, Wi-Fi, Bluetooth, and NFC). Additionally, the cross-platform bridge may perform functions such as executing binaries on a native operating system (e.g., the operating system used by the DUT), executing characterization tests, executing debug tests, executing production tests, and determining the minimum voltage at which the DUT can operate, for example, but not limited to.

[0036] Therefore, the disclosed test system provides a fully integrated ecosystem that automates the entire execution of any test program directly on the DUT.

[0037] FIG. 1 is a block diagram showing selected elements of a test system (100) in an embodiment according to the present invention. The test system (100) may include elements other than those shown and described, and may include a different number of elements than those shown and described.

[0038] In the embodiment of FIG. 1, the test system (100) includes what may be referred to herein as a client (or customer) ecosystem and a vendor (or tester) ecosystem. For example, the client ecosystem may include a client system (101 and 102), and the vendor ecosystem may include an intermediary device (106) and a test assembly (110).

[0039] Generally, the client system (101) includes a computer system or a network of computer systems belonging to a client entity that has exclusive rights or similar rights over the DUT in some way. The client system (102) is a similar type of system or network. The client systems (101 and 102) can communicate with the test system (100) through an intermediary device (106). For example, the client systems (101 and 102) can provide their respective test programs to the test system (100) through the intermediary device (106). This allows the clients to write their own custom commands and test programs for their respective DUTs. Additionally, the client systems (101 and 102) can receive test results of their respective DUTs from the test system (100) through the intermediary device (106). Additionally, the client systems (101 and 102) can be used for remote participation and / or management of the testing of their respective DUTs. For example, client systems (101 and 102) can analyze the test results for their respective DUTs and use the analysis results as feedback for the next test step. Thus, the test can be made available on computer systems anywhere in the world, and remote entities can perform the test as if they had physical access to the test equipment.

[0040] In one embodiment, the intermediary device (106) is a proxy server. Client systems (101 and 102) can remotely access and log in to the intermediary device (106) using, for example, an IP address and some form of authentication (e.g., a password), and the intermediary device then forwards the respective remote logins to allow secure access to a private network including part of the vendor ecosystem downstream of the intermediary device. Thus, the client systems (101 and 102) can be located anywhere in the world where internet access is available. In one embodiment, the intermediary device (106) is implemented using a rack-integrated computer system (RIC). However, the invention is not limited thereto.

[0041] In the embodiment of FIG. 1, the test assembly (110) includes a plurality of PDBs and a plurality of TIBs. The TIBs and PDBs may be installed in a test rack (see, for example, FIG. 6a and 6b). In the example of FIG. 1, the test assembly (110) includes a PDB (120) and TIBs (131 and 132). The PDB (120) controls the power supply to the TIBs (131 and 132). Here and in the description below, the test assembly (110) may include any practical number of the described hardware elements. That is, for example, an embodiment according to the present invention may include more than one PDB, more than or less than two TIBs, more than or less than four DUTs, etc.

[0042] The PDB (120) includes a plurality of connection interfaces configured to be connected to a similar number of computing units, represented by computing units (121 and 122). For example, computing units (121 and 122) may be plugged into sockets on the PDB (120), but the invention is not limited thereto.

[0043] In one embodiment, each computing unit (121 and 122) is a single-board computer (SBC). The computing units (121 and 122) are described in more detail below in relation to FIG. 2. Generally, the computing units (121 and 122) execute active control software that runs a test program on the DUT by sending commands to the DUT.

[0044] Referring further to the example in FIG. 1, each TIB (131 and 132) includes a plurality of connection interfaces configured to be connected to a similar number of DUTs (e.g., DUTs (141, 142, 143 and 144)). As described in more detail herein, the DUTs (141-144) may have different form factors (e.g., different shapes or sizes). Accordingly, in one embodiment, the connection interfaces on the TIBs (131 and 132) may be customized or configured to accommodate different form factors (see also the description of FIG. 4 below). The DUT (141-144) may be any type of device, such as, but not limited to, a telephone (e.g., a smartphone), a laptop, a tablet, a workstation, a controller (e.g., a game controller), a watch, a central processing unit (CPU), a graphics processing unit (GPU), a sensor, a sensor input board (SIB), or a gadget (e.g., a USB-connected gadget and a PCIe-connected gadget). Additionally, the DUT (141-144) may be an individual component of such a device.

[0045] In one embodiment, the test system (100) also includes a computer system (150) or is communicably coupled to the computer system (150). The computer system (150) may be an RIC, or may be communicably coupled to the test assembly (110) through a switch, such as an Ethernet switch, for example. The computer system (150) may be used as a system controller for managing the test system (100), particularly the automated test equipment (ATE) and integrated development environment (IDE), including coordinating tests across the SBC and TIB of the test system (100).

[0046] FIG. 2 is a block diagram showing selected elements of a computing unit (200) in an embodiment according to the present invention. The computing unit (200) is an example of the computing unit (121 and 122) of FIG. 1. In some embodiments, the computing unit (200) is implemented as a single-board computer (SBC) and includes a processor (202) and memory (204) coupled to the processor. The computing unit (200) may include other components common in conventional computer systems, such as a display device and a user input device, but this computing unit / SBC can perform its function without such elements.

[0047] Additionally, the computing unit (200) of FIG. 2 includes a first communication interface (211) operable to communicate bidirectionally with an external device. In some embodiments, the first communication interface (211) is operable to communicate bidirectionally with an intermediary device (106). Alternatively, the first communication interface (211) may be used to communicate bidirectionally directly with a client system by bypassing the intermediary device (106). In one embodiment, the first communication interface (211) is an Ethernet driver. The first communication interface (211) may communicate with an external device via a wired connection or a wireless connection (e.g., Wi-Fi, Bluetooth, and NFC), or both wired and wireless communication may be possible. In one embodiment, the computing unit (200) has more than one number of communication interfaces operable to communicate bidirectionally with a second external device (e.g., the computer system (150) of FIG. 1 and / or another intermediary device / proxy server).

[0048] Additionally, the computing unit (200) of FIG. 2 generally includes a second communication interface (212) operable to communicate bidirectionally with one or more DUTs on the TIB (131 and 132) ( FIG. 1) and, in particular, with one or more DUTs on the TIB. For example, the second communication interface (212) may be communicably coupled to any one of the DUTs (141-144) or any combination of two or more of the DUTs (141-144) (see examples in FIG. 5a, 5b, 5c and 5d below). In one embodiment, the second communication interface (212) is a USB universal connector. In another embodiment, it is an asynchronous transceiver (UART) connector. And in yet another embodiment, it is a PCIe connector. The second communication interface (212) may communicate with the DUTs (141, 142, 143 and / or 144) via a wired connection or a wireless connection, or may be capable of both wired and wireless communication. Accordingly, the computing unit (200) supports one or both of conduction testing and OTA (over-the-air). Additionally, multiple transmit (Tx) and receive (Rx) power levels are supported. Furthermore, MIMO (multiple input and multiple output) antenna sharing is supported. Tests can be performed in various frequency bands. In one embodiment, the computing unit (200) has more than one of these communication interfaces so that it can communicate with more than one DUT or more than one group of DUTs simultaneously.

[0049] Thanks to wired and wireless capabilities, the second communication interface (212) can be used for RF, cellular, and connectivity tests on the DUT (141, 142, 143 and / or 144). Cellular testing includes all low, medium, high, and ultra-high frequencies (e.g., about 400 MHz to about 7 GHz). Thus, the computing unit (200) can test, for example, 4G and 5G cellular, Wi-Fi, Bluetooth, NFC, and GPS (Global Positioning System) functions and components on the DUT.

[0050] The computing unit (200) may operate to run different operating systems independently and simultaneously. For example, the computing unit (200) may have different operating system environments running simultaneously on the same hardware by using virtualization technology or by partitioning memory (204), but the present invention is not limited thereto. Operating systems that can be run by the computing unit (200) include, but are not limited to, Linux operating systems, Windows operating systems, Android® operating systems, and Apple® operating systems.

[0051] A single computing unit / SBC (e.g., computing unit (200)) can communicate with a single DUT or multiple DUTs and control their tests. The DUTs controlled by a single SBC may be of the same type or different types of DUTs. For example, the DUTs controlled by a single SBC may use the various operating systems discussed above, or have different form factors, or have different characteristics (e.g., different operating voltages and currents), or run different test programs, or have different features (e.g., one DUT may have a display device and the other may not), or have different components (e.g., different processors). Embodiments according to the present invention are not limited to these examples.

[0052] Additionally, the computing unit (200) can be further operated to perform other operations and functions in its role as an overall test orchestrator. In some embodiments, the computing unit (200) determines the type of each DUT to be tested before testing and selects an operating system compatible with that type of DUT. The type of DUT is determined automatically without the need for user intervention. Several examples of device types are mentioned above.

[0053] Additionally, in some embodiments, the computing unit (200) identifies the location of each DUT to be tested within the test assembly (110) (Fig. 1) before testing. Generally, the computing unit (200) identifies and enumerates the connected DUTs and constructs a map of the locations of each DUT that can be used during testing. In one embodiment, this map may be displayed on a local computer (e.g., computer system (150)) that specifically monitors the test assembly (110) or monitors the entire test system (100).

[0054] In some embodiments, the computing unit (200) receives a test program from one or more client systems (e.g., client systems (101 and 102) of FIG. 1). This allows the clients to communicate with their specific DUTs by writing their own custom commands and test programs. In one embodiment, the computing unit stores the received test programs in memory (204). In some embodiments, the computing unit (200) associates each received test program with each DUT to be tested using each test program. In some embodiments, the computing unit (200) issues a command to execute the test program to each DUT to be tested using each test program and an operating system compatible with each DUT type.

[0055] In some embodiments, the computing unit (200) of FIG. 2 provides an execution context for executing a test program to a set of DUTs to be tested using each test program, and also executes an executable binary (e.g., C#, Java®, and Python®) and low-level embedded code to perform DUT functions during testing. In some embodiments, the computing unit (200) executes the binary and low-level embedded code on an operating system used by the set of DUTs.

[0056] In some embodiments, the computing unit (200) sets individual voltage levels and individual current levels for testing the components of the DUT being tested. More specifically, for example, the computing unit (200) can set appropriate voltage and current levels for testing individual components connected to the DUT.

[0057] In some embodiments, the computing unit (200) receives test results from the DUT being tested. In one embodiment, the computing unit (200) stores the test results. In one embodiment, the computing unit (200) post-processes the test results. In another embodiment, the computing unit (200) processes the test results while the test is being performed. Thus, in these embodiments, the computing unit (200) can collect data, analyze the data, and use the analysis results as feedback for the next test step.

[0058] In some embodiments, the processing performed by the computing unit (200) may include real-time processing and post-processing of test results, and may include integrating and executing a third-party framework. For example, an image of the phone being tested may be captured during the test, and an image processing algorithm (e.g., an artificial intelligence algorithm) may be deployed to transform or analyze the phone's behavior. As another example, during a functional test of the DUT, the temperature and power profile of the DUT may be determined and analyzed.

[0059] In some embodiments, the computing unit (200) collects test results for a set of DUTs associated with a specific client system (e.g., client system (101) of FIG. 1) into a data package and transmits this data package to each client system directly or through an intermediary device (106) via a first communication interface (211). In other words, when a specific type of device is being tested for a customer, the test results for each type of device can be collected and packaged by the computing unit (200) and transmitted to each customer.

[0060] Accordingly, as just described, a single computing unit / SBC (e.g., computing unit (200)) has the capability to provide seamless bidirectional communication between the client (or customer) ecosystem and the vendor (or tester) ecosystem. Both ecosystems can communicate seamlessly with each other without needing to know the full details of how the other ecosystem operates. Additionally, since each computing unit / SBC has the capability to communicate with and control various types of DUTs, various devices (e.g., different types of DUTs) can be tested simultaneously without requiring a tester ecosystem dedicated to any specific type of device. In this way, the test system (100) provides a fully integrated ecosystem for automating the entire execution of any test program directly on the DUT. Consequently, each computing unit / SBC can be characterized and referred to as a cross-platform bridge or bridging component. A group of these computing units / SBCs on the PDB can also be collectively characterized and referred to as a cross-platform bridge or bridging component.

[0061] FIG. 3 is a block diagram of an example of a power distribution board (e.g., PDB (120)) in an embodiment according to the present invention. In this figure, the PDB (120) is connected to a plurality of computing units / SBCs (e.g., SBCs (121 and 122)). In one embodiment, a master controller (310) is also connected to the PDB (120) and is communically coupled to the computing units / SBCs. The master controller (310) can manage and coordinate the execution of a test program by the plurality of computing units / SBCs. For example, the computing units / SBCs (121 and 122) can operate in tandem to execute the same test program or different parts of the same test program across a plurality of DUTs under the control of the master controller (310).

[0062] FIG. 4 is a block diagram of an example of a test interface board (e.g., TIB (131)) in an embodiment according to the present invention. In the example of FIG. 4, the TIB (131) includes a plurality of connection interfaces or slots (e.g., connection interfaces (411 and 412)). Each connection interface is configured to be connected to each DUT (e.g., DUT (141 and 142)). The DUTs (141 and 142) may have different form factors (e.g., different shapes or sizes).

[0063] In one embodiment, each connection interface (411 and 412) includes a mechanical insert of a size and shape to accommodate the form factor of each DUT. For example, the DUT (141) may be a smartphone and the DUT (142) may be a tablet, in which case the connection interface (411) has a size and shape to securely hold the smartphone in place and the connection interface (412) has a size and shape to securely hold the tablet in place.

[0064] In one embodiment, the connection interfaces (411 and 412) can be removed from the TIB (131) so that one connection interface can be replaced with another connection interface depending on the form factor of the DUT to be tested. For example, a connection interface pre-sized for a specific form factor can be removed and replaced with a connection interface pre-sized for a different form factor.

[0065] In another embodiment, the connection interfaces (411 and 412) are reconfigurable. For example, sides of the connection interfaces can be moved or adjusted in other ways to form various sizes and shapes that match the form factor of the DUT.

[0066] Accordingly, in some embodiments, each TIB can be customized to accommodate different form factors. More specifically, in some embodiments, connection interfaces on the TIB can be customized to accommodate different form factors. Thus, different types of DUTs can be easily replaced on the TIB, the TIB can be easily adapted to accommodate DUTs of any type or form factor, and the TIB can also be easily adapted to accommodate new types of devices, non-standard or prototype devices with new form factors.

[0067] FIG. 5a is a block diagram showing an example of a test setup within a test system (100) (Fig. 1) or a test assembly (110) in one embodiment according to the present invention. In the example of FIG. 5a and other examples of this specification, the PDB (120) is shown having four computing units / SBCs (121, 122, 511 and 512), and the TIB (131) is shown having four DUTs (141-144). However, the present invention is not limited thereto, and the PDB may accommodate any practical number of computing units / SBCs, and the TIB may accommodate any practical number of DUTs. The computing units / SBCs (511 and 512) may be connected to other DUTs (not shown).

[0068] In the example of FIG. 5a, there is a one-to-one arrangement or mapping between the SBC and the DUT. Specifically, in this example, the computing unit / SBC (121) is connected only to the DUT (141) (communicably coupled), and the computing unit / SBC (122) is connected only to the DUT (142) (communicably coupled). In this example and other examples of the specification, the connection between the SBC / computing unit and the DUT may be a wired connection and / or a wireless connection.

[0069] In the example of FIG. 5a, each computing unit / SBC on the PDB (120) can be connected to a respective DUT on the TIB (131). Additionally, one or more computing units / SBCs on the PDB (120) can be connected to a respective DUT on one TIB, and one or more other computing units / SBCs on the PDB (120) can be connected to a respective DUT on a different TIB. Generally, computing units / SBCs on the PDB (120) can be connected to a respective DUT on one or more TIBs. Thus, in this example and the example below, the test system (100) and the test assembly (110) allow for a great deal of flexibility when preparing the test setup.

[0070] Furthermore, in the example of FIG. 5a and other examples of this specification, testing of individual DUTs or sets of DUTs can be performed simultaneously. Consequently, many DUTs can be tested in parallel. This provides numerous advantages. For example, the test system throughput is increased. Different types of devices can be tested simultaneously. For example, laptops and telephones can be tested independently at the same time. Additionally, different test programs can be executed simultaneously on devices of the same type. For example, while functional testing is performed on one type of telephone, debugging operations can be performed on another telephone of the same type.

[0071] FIG. 5b is a block diagram showing another example of a test setup within a test system (100) (Fig. 1) or a test assembly (110) in one embodiment according to the present invention. In the example of FIG. 5b, there is a many-to-one (N-to-one) arrangement or mapping between the SBC and the DUT. Specifically, in this example, the computing unit / SBC (121) is connected to (communicably coupled to) the DUTs (141-143). In this example, N is 3, but the present invention is not limited thereto. N can be any practical integer value. Other computing units / SBCs on the PDB (120) may be coupled to a plurality of DUTs or a single DUT, similar to the example of FIG. 5a.

[0072] In one embodiment, in this example and the example below, when the computing unit / SBC (121) issues a command for a test, each command is automatically replicated to all N DUTs. Then, the computing unit / SBC (121) waits for the test to be completed on all N DUTs or waits for an allocated time to elapse. When the test is completed and any results are received, the computing unit / SBC (121) can package the results and transmit them to an appropriate client ecosystem, as previously described in this specification.

[0073] In the example of FIG. 5b, the computing unit / SBC (121) is connected to multiple DUTs on the TIB (131). As previously explained, since the computing unit / SBC (121) can run different operating systems independently and simultaneously, the DUTs connected to the computing unit / SBC (121) may be different types of DUTs. Generally, each computing unit / SBC on the PDB (120) may be connected to one or more DUTs and one or more types of DUTs. Thus, as described above, the example of FIG. 5b advantageously provides flexibility when preparing the test setup.

[0074] Additionally, in the example of FIG. 5b, all DUTs are shown as being on the same TIB, but the invention is not limited thereto. That is, DUTs coupled / connected to the computing unit / SBC (121) may be on different TIBs.

[0075] FIG. 5c is a block diagram showing another example of a test setup within a test system (100) (Fig. 1) or a test assembly (110) in one embodiment according to the present invention. In the example of FIG. 5c, there is a many-to-one (N-to-one) arrangement or mapping between the SBC and the DUT. Specifically, the computing unit / SBC (121) is connected (communicably coupled) to the DUTs (141, 142, and 144) on the TIB (131) and to the DUTs (541, 542, and 543) on the TIB (132). In this example, N is 3, but the present invention is not limited thereto. N can be any practical integer value. Other computing units / SBCs on the PDB (120) may be coupled to a plurality of DUTs or a single DUT, similar to the example of FIG. 5a.

[0076] As in the example of FIG. 5b, the DUTs connected to the computing unit / SBC (121) may be different types of DUTs. Generally, each computing unit / SBC on the PDB (120) may be connected to one or more DUTs on one or more TIBs and one or more types of DUTs. Thus, as discussed above, the example of FIG. 5c advantageously provides flexibility when preparing the test setup.

[0077] FIG. 5d is a block diagram showing another example of a test setup within a test system (100) (Fig. 1) or a test assembly (110) in one embodiment according to the present invention. In the example of FIG. 5d, a computing unit / SBC (121) is connected to (communicably coupled to) a DUT (551), which is then connected to (communicably coupled to) a DUT (552), which is also connected to (communicably coupled to) a computing unit / SBC (121). This arrangement represents a case where the output of one DUT (e.g., DUT (551)) affects the performance of another DUT (e.g., DUT (552)).

[0078] For example, an autonomous vehicle may be equipped with a blind-spot sensor. The output of the blind-spot sensor may be provided to a second sensor that determines whether a turn signal is activated or whether the vehicle is changing direction or changing lanes. When the turn signal is activated, the second sensor may react in a specific way (e.g., by generating a type of warning that results in a type of vehicle response). And, when the vehicle is changing direction or changing lanes, the second sensor may react in a different way (e.g., by generating a second type of warning that results in a second type of vehicle response).

[0079] To test a scenario as just described, the result or output of a test of the DUT (551) is transmitted to the DUT (552), the DUT (552) is tested based on the information received from the DUT (551), and the result or output from the DUT (552) is transmitted to the computing unit / SBC (121). Two or more DUTs may be connected in any practical configuration to mirror configurations of various real-world applications similar to those described above. In general, the example of FIG. 5d advantageously provides flexibility when preparing the test setup.

[0080] FIGS. 6a and 6b illustrate examples of selected elements within a test assembly (110) of a test assembly (e.g., FIGS. 1 and 5a-5d) in an embodiment according to the present invention. Specifically, FIG. 6a illustrates an example of a PDB (120) and a TIB (131) in an embodiment according to the present invention, and FIG. 6b illustrates an example of a test rack (or test chassis) (610) in an embodiment according to the present invention. A pair of boards including a PDB and a TIB may be referred to as a test block.

[0081] In the example of FIG. 6a, the test block (611) includes a PDB (120) and a TIB (131). As previously described in this specification, the PDB (120) may include one or more computing units / SBCs (e.g., computing units / SBCs (121)), and the TIB (131) may include one or more DUTs (e.g., DUTs (141)).

[0082] In the example of FIG. 6b, the test rack (610) includes a plurality of slots or some other means to support test blocks within the test rack. The test assembly (110) (Figs. 1 and 5a-5d) may include another test rack adjacent to or near the test rack (610). In the example of FIG. 6b, the test rack (610) includes two test blocks (611 and 612). However, the invention is not limited thereto, and the test rack may include any practical number of test blocks.

[0083] A computing unit / SBC within a test block (611) may be communicably coupled to one or more DUTs within a TIB (131) and / or to one or more DUTs within any other TIB or test block within a test rack (610) or another test rack (not shown) of a test assembly (110) (Figs. 1 and 5a-5d), as described above in this specification. Additionally, the DUTs within the test block (611) may be communicably coupled to any computing unit / SBC on a PDB (120) or to any computing unit / SBC on any other PDB or test block within a test rack (610) or another test rack of a test assembly (110), as described above in this specification. The same applies to a test block (612).

[0084] Multiple (e.g., two or more) test blocks may be grouped together to form a test block group (e.g., test block groups (631 and 632) of FIG. 6b). Test blocks within a test block group may be adjacent to each other within a test rack (610), but the present invention is not limited thereto. Each test block and each test block group facilitates and enables device isolation and compartmentalization to ensure the integrity and security of the test. More specifically, a test block or test block group may be coupled to communicate with a single or individual client system (e.g., client system (101 or 102) of FIG. 1). Each client system may communicate only with a test block or test block group that includes DUTs belonging to that client system. Thus, a client system (e.g., client system (101)) may provide a test program only to its own DUT, for instance, and receive test results only from its own DUT. Conversely, other client systems (e.g., client system (102)) cannot communicate with the DUTs belonging to the client system (101) or receive test results from the DUTs. Consequently, each test block or group of test blocks can be isolated and tested independently, and communication between the client system and its respective DUTs is protected.

[0085] FIG. 7 is a flowchart (700) of an example of a method performed by a computing unit (cross-platform bridge) within a test assembly (e.g., a computing unit / SBC (121) within the test assembly (110) of FIG. 1) in an embodiment according to the present invention. FIG. 8 is a flowchart (800) of an example of a method performed by a computing unit (cross-platform bridge) within a test assembly (e.g., a computing unit / SBC (121) within the test assembly (110) of FIG. 1) in an embodiment according to the present invention. FIG. 9 is a flowchart (900) of an example of a method performed by a test system (e.g., a test system (100) of FIG. 1) in an embodiment according to the present invention. FIG. 7 through 9 are described with reference to the drawings discussed above. The method described in the examples of FIG. 7 through 9 may be performed using possible combinations of the elements described in the previous drawings.

[0086] In block (702) of FIG. 7, a test program is received from an external system (e.g., an intermediary device (106) or a client system (101 or 102)). The test program is intended to test a DUT (e.g., one or more of DUTs (141-144)) that is communicably coupled to one or more TIBs (e.g., TIBs (131 and 132)) of the computing unit and test assembly (110). The TIBs are configured to be connected to different types of devices having different form factors.

[0087] In block (704), the type of DUT(s) is determined.

[0088] In block (706), each position on the test interface board(s) of each DUT(s) is determined.

[0089] In block (708), among a number of operating systems residing on the computing unit and executable by the computing unit, an operating system compatible with each DUT type is selected.

[0090] In block (710), a command to execute a test program on each DUT using a selected operating system is issued, and the test program is executed. In some embodiments, a context for executing the test program is also provided. In some embodiments, individual voltage levels and individual current levels for testing the components of each DUT are set by a computing unit. In some embodiments, a third-party framework is integrated into the test program and executed during the test.

[0091] In block (712), the test results of the DUT(s) are received. In some embodiments, these results are stored in the memory of a computing unit (e.g., memory (204) of FIG. 2). In some embodiments, the test results are processed. In some embodiments, the test results are analyzed while the test is being performed, and the analysis results are used as feedback for other test steps.

[0092] In block (714), the test results are transmitted to an external system. In some embodiments, a data package containing a compilation of test results is generated, and this data package is transmitted to an external system.

[0093] In block (802) of FIG. 8, a connection is detected between one or more test interface boards (e.g., TIBs (131 and 132)) and DUTs (e.g., one or more DUTs (141-144)) within a test rack (e.g., test rack (610) of FIG. 6b) that are communicably coupled with a computing unit. The DUTs within the test rack may include different types of devices having different form factors.

[0094] In block (804), a test program is accessed from the memory of the computing unit (e.g., the memory (204) of FIG. 2), which is associated with a set of DUTs. This set may include one or more of the DUTs (141-144).

[0095] In block (806), the test program is mapped to a location within the test rack of each DUT of the set of DUT(s).

[0096] In block (808), one operating system compatible with the device type in the set of DUTs is selected from among a plurality of operating systems residing in the memory of the computing unit.

[0097] In block (810), the test program is executed on each DUT within the set of DUT(s) using this operating system.

[0098] In block (902) of FIG. 9, a plurality of test programs are received from computing units (e.g., computing units (121 and 122) of FIG. 1) on a power distribution board (e.g., PDB (120)) within a test assembly (e.g., test assembly (110)) of a test system (e.g., test system (100)). The test programs are intended to test DUTs (e.g., DUTs (141-144)) within one or more test racks (e.g., test rack (610) of FIG. 6b) of the test system or test assembly. Each test program includes a respective command for testing a respective set of DUTs.

[0099] In block (904), the first test program is mapped to a location within the test assembly of each DUT of the first set of DUT(s), and the first set of DUT(s) is associated with the first test program and uses the first operating system.

[0100] In block (906), the second test program is mapped to a location within the test assembly of each DUT of the second set of DUT(s), and the second set of DUT(s) uses a second operating system that is associated with the second test program and is different from the first operating system.

[0101] In some embodiments, the test assembly includes a plurality of test interface boards, and a first set of DUT(s) is connected to a first test interface board within the test assembly, and a second set of DUT(s) is connected to a second test interface board within the test assembly. In other embodiments, the first set of DUT(s) and the second set of DUT(s) are connected to the same test interface board. In some embodiments, the first and second test interface boards are in the same test rack. In some embodiments, the first and second test interface boards are in different test racks within the test assembly.

[0102] In block (908), a first test program is executed on each DUT in the first set of DUTs using a first operating system.

[0103] In block (910), a second test program is executed on each DUT within the second set of DUTs using a second operating system, and the second test program is executed simultaneously with the execution of the first test program. In some embodiments, the first test program and the second test program are executed simultaneously by the same computing unit.

[0104] In block (912), the result of testing the first set of DUT(s) is transmitted to the first client system.

[0105] In block (914), the results of testing the second set of DUTs are transmitted to the second client system.

[0106] In summary, the disclosed technology overcomes the limitations of conventional systems and methods by introducing a cross-platform bridge (e.g., a computing unit or multiple computing units) that acts as a whole test orchestrator and can perform various functions across multiple platforms (e.g., operating systems) and DUT types. Various types of DUTs can be tested without the need to change the tester ecosystem. Furthermore, seamless bidirectional communication with the DUT's hardware, bare metal, and firmware is simplified. The cross-platform bridge is designed to operate appropriately on various (possibly arbitrary) platforms or devices, regardless of the specific hardware used by each platform or device.

[0107] At least one technical advantage of an embodiment according to the present invention is that a single computing unit / SBC or cross-platform bridge has the capability to provide seamless bidirectional communication between a client (or customer) ecosystem and a vendor (or tester) ecosystem. Both ecosystems can communicate seamlessly with each other without fully knowing the details of how the other ecosystem operates. Additionally, each computing unit / SBC has the capability to communicate with and control different types of DUTs, thereby enabling simultaneous testing of various devices without requiring a tester ecosystem dedicated to any single specific type of device. Each computing unit / SBC facilitates the implementation of device isolation, thereby ensuring the integrity and security of the test.

[0108] Other technical advantages provided by embodiments according to the present invention include the ability to execute the same tests as those executed on an SLT chip on a DUT, the ability to perform stress tests and connectivity tests in an integrated ecosystem, and the ability to perform advanced debugging test sessions on a DUT while digital tests and connectivity tests are executed in parallel on a plurality of different DUTs.

[0109] Clause 1. In some embodiments, the computing unit comprises: a first communication interface operable to receive a plurality of test programs for testing a plurality of devices operable to the computing unit from an external system operable to the computing unit; a second communication interface operable to transmit a command for executing the plurality of test programs to the plurality of devices and to receive test results from the plurality of devices—the first communication interface is also operable to transmit test results to an external system—and a processor coupled to the first communication interface and the second communication interface, wherein the processor is operable to determine a device type for a set of devices including one or more of the plurality of devices, associate one of the plurality of test programs with the set of devices, and issue a command for executing the test program to each device in the set of devices using an operating system compatible with the device type.

[0110] Clause 2. As a computing unit of Clause 1, a plurality of devices are coupled to a test interface board within a test rack and include different types of devices having different form factors.

[0111] Clause 3. As a computing unit of Clause 1 or 2, the computing unit can operate to determine each location within the test interface board of each device in the device set.

[0112] Clause 4. As a computing unit of any one of Clauses 1 to 3, it is configured to run multiple different operating systems.

[0113] Clause 5. A computing unit of any one of Clauses 1 to 4, wherein the computing unit is a single-board computer capable of operating to use various communication protocols, the first communication interface is an Ethernet driver, the second communication interface is selected from the group consisting of a Universal Serial Bus (USB) universal connector, an asynchronous transceiver connector, and a Peripheral Component Interconnect Express (PCIE) connector, and the external system is a computer system selected from the group consisting of a proxy server and a client system.

[0114] Clause 6. As a computing unit of any one of Clauses 1 through 5, the computing unit can operate to generate a data package containing a compilation of results of testing each device in a set of devices, and to transmit the data package to an external system through a first communication interface.

[0115] Clause 7. As a computing unit of any one of Clauses 1 through 6, the test is a type of test selected from the group consisting of system-level tests, functional tests, and scan tests.

[0116] Clause 8. As a computing unit of any one of Clauses 1 through 7, the computing unit further comprises memory coupled to a processor, and the memory is operable to store the results of testing each device in a set of devices.

[0117] Clause 9. As a computing unit of any one of Clauses 1 through 8, the processor may further operate to process the results of testing each device in the device set.

[0118] Clause 10. In some embodiments, the test assembly comprises a test interface board including a plurality of connection interfaces, wherein each connection interface of the plurality of connection interfaces is configured to be connected to each of the plurality of device under test (DUT)s, and a power distribution board coupled to a plurality of computing units, wherein each of the computing units is configured to be connected to a set of each DUT including one or more of the plurality of DUTs, and each computing unit is capable of determining the type of DUTs in the set of each DUT, selecting one operating system among a plurality of operating systems that is compatible with the type of DUTs in the set of each DUT, and using the operating system to execute a test program on each DUT in the set of each DUT.

[0119] Clause 11. As a test assembly of Clause 10, each computing unit can be further operated to determine the location of each DUT within each set of DUTs within the test interface board.

[0120] Clause 12. As a test assembly of Clause 10 or 11, each computing unit comprises a single-board computer capable of operating to use various communication protocols, including a processor and memory, a first communication interface comprising an Ethernet driver coupled to the processor and capable of operating to communicate with an external system, and a second communication interface coupled to the processor and capable of operating to communicate with each set of DUTs, comprising a connector selected from a group consisting of a USB universal connector, an asynchronous transceiver connector, and a PCIE connector.

[0121] Clause 13. As a test assembly of any one of Clauses 10 to 12, a plurality of DUTs connected to a test interface board include different types of devices having different form factors.

[0122] Clause 14. As a test assembly of any one of Clauses 10 to 13, each computing unit comprises a memory, a processor coupled to the memory and operable to generate a data package comprising a set of test results for each DUT in each set of DUTs, and a communication interface coupled to the processor and operable to transmit the data package to an external system.

[0123] Clause 15. As a test assembly of any one of Clauses 10 to 13, each computing unit comprises a memory operable to store the results of testing each DUT in each set of DUTs, and a processor coupled to the memory and operable to process the results of testing each DUT in each set of DUTs.

[0124] Clause 16. In some embodiments, the system comprises a test assembly and an intermediary device coupled to the test assembly, wherein the test assembly comprises a test interface board having a plurality of connection interfaces, each connection interface of the plurality of connection interfaces configured to be connected to each of the plurality of device under test (DUT)s, and a plurality of computing units coupled to a power distribution board, wherein the intermediary device is operable to provide remote access to the plurality of computing units, and one of the computing units comprises a cross-platform bridge configured to be connected to a set of DUTs including one or more DUTs associated with a client system, and is operable to run a plurality of different operating systems, identify the location of each DUT of the set of DUTs on the test interface board, determine the type of DUT within the set of DUTs, receive a test program including a plurality of commands for testing the set of DUTs from the client system through the intermediary device, execute the test program using one of the plurality of different operating systems compatible with the type of DUT within the set of DUTs, and transmit the test results to the client system through the intermediary device.

[0125] Clause 17. As a system of Clause 16, the computing unit comprises a single-board computer including a processor and memory and operable to use various communication protocols, a first communication interface including an Ethernet driver coupled to the processor and operable to communicate with an intermediary device, and a second communication interface including a connector selected from a group consisting of a USB universal connector, an asynchronous transceiver connector, and a PCIE connector, coupled to the processor.

[0126] Clause 18. As a system of Clause 16 or 17, a plurality of DUTs connected to a test interface board include different types of devices having different form factors.

[0127] Clause 19. As a system of any one of Clauses 16 through 18, the test assembly further comprises a test rack configured to support one or more test interface boards, each of the one or more test interface boards can be configured for different types of DUTs having different form factors.

[0128] Clause 20. As a system of any one of Clauses 16 to 19, the test assembly further comprises a test rack including a test interface board and a second test interface board, wherein the connection interface of the test interface board is configured to be connected to a first type of DUT, and the connection interface of the second test interface board is configured to be connected to a second type of DUT, and the first type of DUT has a different form factor from the second type of DUT.

[0129] Clause 21. In some embodiments, a method executed by a computing unit in a test assembly comprises: receiving a test program for testing a plurality of devices communicably coupled to one or more test interface boards of the computing unit and the test assembly from an external system operable to communicate with the computing unit; determining a device type for the plurality of devices; determining each location of each of the plurality of devices within one or more test interface boards; selecting an operating system compatible with the device type among a plurality of different operating systems that the computing unit can execute; issuing a command to execute the test program on each device using the selected operating system; receiving test results of the plurality of devices; and transmitting the test results to an external system.

[0130] Clause 22. As a method of Clause 21, one or more test interface boards are configured to be connected to different types of devices having different form factors.

[0131] Clause 23. As a method of Clause 21 or 22, further includes the step of providing a context for executing a test program.

[0132] Clause 24. As a method of any one of Clauses 21 to 23, the computing unit comprises a single-board computer capable of operating to use various communication protocols, including a processor and memory, a first communication interface for receiving a plurality of test programs from an external system and transmitting test results to the external system, and a second communication interface for transmitting commands to each device and receiving test results, wherein the external system is a computer system selected from a group consisting of a proxy server and a client system.

[0133] Clause 25. Any one of Clauses 21 to 24 further comprises the steps of generating a data package containing a set of test results of each device and transmitting the data package to an external system through a first communication interface.

[0134] Clause 26. As a method of any one of Clauses 21 to 25, the method further includes the step of storing the test results of each device in the memory of the computing unit.

[0135] Clause 27. Any one of Clauses 21 to 26 further includes the step of processing the test results of each device.

[0136] Clause 28. As a method of any one of Clauses 21 to 27, the method further includes the step of setting a respective voltage level and a respective current level for testing a component of each device.

[0137] Clause 29. As a method of any one of Clauses 21 through 28, it further includes a step of analyzing test results while the test is being performed and a step of using the results of the analysis step as feedback for the next test step.

[0138] Clause 30. As a method of any one of Clauses 21 through 29, further include the step of integrating a third-party framework into the test.

[0139] Clause 31. In some embodiments, a method executed by a computing unit connected to a power distribution board in a test assembly comprises: detecting a connection between one or more test interface boards located in a test rack and communicably coupled to the computing unit and a plurality of devices under test (DUTs); accessing a test program associated with one set of DUTs among the plurality of DUTs from the memory of the computing unit; mapping the test program to a location in the test rack of each DUT of the set of DUTs; selecting an operating system compatible with the type of device in the set of DUTs from among a plurality of operating systems residing in the memory of the computing unit; and executing the test program on each DUT in the set of DUTs using the operating system.

[0140] Clause 32. As a method of Clause 31, a plurality of DUTs in a test rack include different types of devices having different form factors, and the method further includes the step of determining the type of device in the set of DUTs.

[0141] Clause 33. As a method of Clause 31 or 32, further includes the step of providing a context for running a test program.

[0142] Clause 34. Any one of Clauses 31 to 33 further comprises the step of receiving the result of testing the DUT set and the step of storing the result in the memory of a computing unit.

[0143] Clause 35. Any one of Clauses 31 to 34 further comprises the step of receiving the result of testing the DUT set and the step of processing the result by a processor of a computing unit.

[0144] Clause 36. In some embodiments, a method executed in a test system comprising a plurality of computing units connected to a power distribution board comprises: receiving a plurality of test programs for testing a plurality of devices under test (DUTs) in one or more test racks within a test assembly of the test system from a plurality of client systems communically coupled to the test system in the plurality of computing units, wherein each test program of the plurality of test programs comprises a respective command for testing a set of DUTs among the plurality of DUTs; mapping a first test program among the plurality of test programs to a location within the test assembly of each DUT of a first set of DUTs among the plurality of DUTs, wherein the first set of DUTs is associated with the first test program and uses a first operating system; mapping a second test program among the plurality of test programs to a location within the test assembly of each DUT of a second set of DUTs among the plurality of DUTs, wherein the second set of DUTs is associated with the second test program and uses a second operating system different from the first operating system; executing the first test program on each DUT within the first set of DUTs using the first operating system; and the second operating system The method includes the step of executing a second test program on each DUT within the second DUT set using the method - the step of executing the second test program is performed simultaneously with the step of executing the first test program - the step of transmitting the result of testing the first DUT set to the first client system among a plurality of client systems, and the step of transmitting the result of testing the second DUT set to the second client system among a plurality of client systems.

[0145] Clause 37. As a method of Clause 36, each computing unit of a plurality of computing units comprises a single-board computer capable of operating to use various communication protocols, a first communication interface coupled to the processor and capable of operating to communicate with an intermediary device coupled to the processor and capable of communicating with a first client system and capable of communicating with a second client system, and a second communication interface coupled to the processor and capable of operating to communicate with one or more of the plurality of DUTs.

[0146] Clause 38. As a method of Clause 36 or 37, a test assembly comprises a plurality of test interface boards, a first set of DUTs is connected to a first test interface board among the plurality of test interface boards, and a second set of DUTs is connected to a second test interface board among the plurality of test interface boards.

[0147] Clause 39. As a method of any one of Clauses 36 to 38, the test assembly includes a plurality of test interface boards, and the first set of DUTs and the second set of DUTs are connected to the same test interface board among the plurality of test interface boards.

[0148] Clause 40. As a method of any one of Clauses 36 to 39, the first DUT set and the second DUT set are both communically coupled to the same computing unit among a plurality of computing units coupled to a power distribution board, and the step of executing the first test program and the step of executing the second test program are performed simultaneously by the same computing unit.

[0149] Any combination of any claim element mentioned in any claim and / or any element described in this application falls within the intended scope and protection scope of the present invention in any way.

[0150] The description of the various embodiments is provided for illustrative purposes only and is not intended to be a thorough description without omission, nor is it intended to be limited to the disclosed embodiments. Many modifications and variations that do not depart from the scope and spirit of the described embodiments will be apparent to those skilled in the art.

[0151] Aspects of the present embodiment may be implemented as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of an implementation entirely in hardware, an implementation entirely in software (including firmware, resident software, microcode, etc.), or an implementation combining software and hardware aspects, all of which may generally be referred to as "module," "system," or "computer" in this specification. Additionally, any hardware and / or software technology, process, function, component, engine, module, or system described in this specification may be implemented as a circuit or set of circuits. Furthermore, aspects of the present invention may take the form of a computer program product implemented within one or more computer-readable media containing computer-readable program code.

[0152] One or more computer-readable media or any combination of media may be utilized. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, as examples but not limiting, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any suitable combination thereof. More specific examples of a computer-readable storage medium (not all of which are listed) may include an electrical connection having one or more wires, a portable computer diskette, a hard disk, RAM, ROM, EPROM, flash memory, optical fiber, CD-ROM, DVD, an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this specification, a computer-readable storage medium may be any tangible medium capable of containing or storing a program used by or associated with a command execution system, device, or device.

[0153] Aspects of the present invention have been described above with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart and / or block diagram and combinations of blocks within the flowchart and / or block diagram may be implemented by computer program instructions. Such computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to create a machine. When executed through a processor of a computer or other programmable data processing device, the instructions may implement the functions / operations specified in the blocks of the flowchart and / or block diagram or the blocks. Such a processor may be, by example but not limited to, a general-purpose processor, a special-purpose processor, an application-specific processor, or a field-programmable gate array.

[0154] The flowcharts and block diagrams in the drawings illustrate the architecture, functions, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block within a flowchart or block diagram may represent a module, segment, or part of code containing one or more executable instructions for implementing a specified logical function(s). Additionally, in some alternative embodiments, the functions indicated within the blocks may occur differently from the order shown in the drawings. For example, two consecutively indicated blocks may actually be executed substantially simultaneously, or the blocks may be executed in reverse order from time to time depending on the related functions. Furthermore, each block of the block diagram and / or flowchart, and combinations of blocks within the block diagram and / or flowchart, may be implemented as a special-purpose hardware-based system or a combination of special-purpose hardware and computer instructions that perform a specified function or operation.

[0155] The above description relates to embodiments of the present invention, but other embodiments and additional embodiments of the present invention may be devised without departing from the basic scope of the present invention, and the scope of the present invention is determined by the claims below.

Claims

Claim 1 A computing unit comprising: a first communication interface operable to receive a plurality of test programs for testing a plurality of devices operable to the computing unit from an external system operable to the computing unit; a second communication interface operable to transmit a command for executing the plurality of test programs to the plurality of devices and to receive test results from the plurality of devices—the first communication interface is also operable to transmit the test results to the external system—and a processor coupled to the first communication interface and the second communication interface, wherein the processor is operable to determine a device type for a device set comprising one or more of the plurality of devices, associate one of the plurality of test programs with the device set, and issue a command for executing the test program to each device in the device set using an operating system compatible with the device type, wherein the plurality of devices includes a first type of device and a second type of device having a form factor different from that of the first type of device, and the second communication interface comprises a first test interface board configured to be connected to the first type of device and a second test interface configured to be connected to the second type of device. A computing unit that is more operable to be connected to a test rack containing a board. Claim 2 delete Claim 3 In claim 1, the computing unit is a computing unit capable of determining each location within the first test interface board or the second test interface board of each device within the device set. Claim 4 A computing unit according to claim 1, wherein the computing unit is configured to execute a plurality of different operating systems, and the processor is further operable to identify and select an operating system used by the set of devices, execute the test program using the selected operating system, and provide a context for the execution. Claim 5 In claim 1, the computing unit is a single-board computer capable of operating to use various communication protocols, comprising a processor and memory, the first communication interface is an Ethernet driver, the second communication interface is selected from a group consisting of a Universal Serial Bus (USB) connector, an asynchronous transceiver connector, and a Peripheral Component Interconnect Express (PCIE) connector, and the external system is a computer system selected from a group consisting of a proxy server and a client system. Claim 6 In claim 1, the computing unit is operable to generate a data package containing a compilation of test results for each of the devices in the set of devices, and to transmit the data package to the external system through the first communication interface. Claim 7 In paragraph 1, the computing unit, wherein the test is a type of test selected from the group consisting of system-level tests, functional tests, and scan tests. Claim 8 In claim 1, the computing unit further comprises memory coupled to the processor, and the computing unit is operable to store the results of testing each of the devices in the set of devices. Claim 9 In claim 1, the processor is a computing unit further operable to process the results of testing each of the devices in the set of devices. Claim 10 A test assembly comprises a test interface board including a plurality of connection interfaces, wherein each connection interface of the plurality of connection interfaces is configured to be connected to a respective DUT among a plurality of devices under test (DUTs), and a power distribution board coupled to a plurality of computing units, wherein each computing unit of the plurality of computing units is configured to be connected to a respective set of DUTs including one or more DUTs among the plurality of DUTs, and each computing unit is operable to determine the type of DUTs within the respective set of DUTs, select one operating system among a plurality of operating systems that is compatible with the type of DUTs within the respective set of DUTs, and execute a test program on each DUT within the respective set of DUTs using the operating system, and the test assembly further comprises a test rack including the test interface board and a second test interface board, wherein the connection interface of the test interface board is configured to be connected to a first type of DUT, and the connection interface of the second test interface board is configured to be connected to a second type of DUT, and the first type of DUT is a form different from the second type of DUT Test assembly having a factor. Claim 11 In paragraph 10, each of the above computing units is a test assembly further operable to determine the location of each of the above DUTs within the respective DUT set, within the test interface board or the second test interface board. Claim 12 In claim 10, each of the above computing units comprises a single-board computer capable of operating to use various communication protocols, a first communication interface coupled to the processor and capable of operating to communicate with an external system, and a second communication interface coupled to the processor and capable of operating to communicate with each set of DUTs, and comprising a connector selected from a group consisting of a USB universal connector, an asynchronous transceiver connector, and a PCIE connector. Claim 13 delete Claim 14 In claim 10, each of the above computing units comprises a memory, a processor coupled to the memory and operable to generate a data package comprising a set of test results for each of the DUTs within each set of DUTs, and a communication interface coupled to the processor and operable to transmit the data package to an external system, wherein the test assembly comprises a memory, a processor coupled to the memory and operable to generate a data package comprising a set of test results for each of the DUTs within each set of DUTs. Claim 15 In claim 10, each computing unit comprises a memory operable to store the results of testing each DUT in each set of each DUT, and a processor coupled to the memory and operable to process the results of testing each DUT in each set of each DUT, in a test assembly. Claim 16 A system comprising a test assembly and an intermediary device coupled to the test assembly, wherein the test assembly comprises a test interface board including a plurality of connection interfaces, wherein each of the plurality of connection interfaces is configured to be connected to a respective DUT among a plurality of DUTs, and a plurality of computing units coupled to a power distribution board, wherein the intermediary device is operable to provide remote access to the plurality of computing units, and one of the plurality of computing units comprises a cross-platform bridge configured to be connected to a set of DUTs including one or more DUTs associated with a client system, and executes a plurality of different operating systems, identifies the location of each DUT of the set of DUTs on the test interface board, determines the type of DUT within the set of DUTs, receives a test program including a plurality of commands for testing the set of DUTs from the client system through the intermediary device, executes the test program using one of the plurality of different operating systems compatible with the type of DUT within the set of DUTs, and is operable to transmit test results to the client system through the intermediary device, and the test assembly also comprises the test interface board and A system further comprising a test rack including a second test interface board, wherein the connection interface of the test interface board is configured to be connected to a first type of DUT, and the connection interface of the second test interface board is configured to be connected to a second type of DUT, and the first type of DUT has a different form factor from the second type of DUT. Claim 17 In claim 16, the computing unit comprises a single-board computer capable of operating to use various communication protocols, including a processor and memory; a first communication interface coupled to the processor and comprising an Ethernet driver capable of communicating with the intermediary device; and a second communication interface coupled to the processor and comprising a connector selected from a group consisting of a USB universal connector, an asynchronous transceiver connector, and a PCIE connector. Claim 18 delete Claim 19 In claim 16, the test rack is configured to support one or more test interface boards, including the test interface board and the second test interface board, and each of the one or more test interface boards is configurable for different types of DUTs having different form factors, a system. Claim 20 delete

Images