Testing systems and methods with cross-platform bridge components

Abstract

A bridging component is implemented as a computing unit, which includes a first communication interface, a second communication interface, and a processor. The computing unit can receive test programs from one or more external systems communicatively coupled to it, the test programs being used to test DUTs communicatively coupled to it. The computing unit can also transmit commands for executing the test programs to the DUTs, receive test results from the DUTs, and transmit the test results to the appropriate external system(s). Furthermore, the computing unit can determine a specific type of each DUT in a set of one or more DUTs, associate a specific test program with that set, and issue commands to execute the specific test program to the DUT(s) in the set using an operating system compatible with that specific type of DUT(s).

Description

[Technical Field]

[0001] Related US Applications

[0002] This application is a continuation of and claims priority to U.S. Application No. 18 / 673,796, filed May 24, 2024, entitled “Testing Systems and Methods with Cross-Platform Bridge Components”, which is incorporated herein by reference in its entirety.

[0003] The present invention relates to a test system and method with cross-platform bridging components. [Previous Technology]

[0004] Background of the Invention

[0005] End-user electronic devices are typically tested to verify their performance and functionality. Multiple test cases can be used to test the device, and the results of the test cases are compared with the expected output. When the test results do not match the expected results of the device under test (DUT), the DUT can be classified as a faulty device or an outlier, or the DUT can be grouped, for example, based on its performance. By removing defective or otherwise unsatisfactory devices during the engineering and manufacturing stages, the yield of quality devices can be significantly improved.

[0006] The device under test (DUT) may include any type of end-user electronic device, such as, but not limited to, computer systems or smartphones, or gadgets or peripheral components connected via Universal Serial Bus (USN) high-speed interconnect-connected gadgets (e.g., electronic devices designed to perform tasks), or wafers or components intended to be integrated into such devices. DUTs are typically tested by automated test equipment (ATE) systems, which can be used to perform complex tests using software and automation to improve testing efficiency.

[0007] A limitation of conventional testing is that it is performed using test systems (end-device "tester ecosystem" or "vendor ecosystem") that are specialized according to the type of DUT. Therefore, if different types of DUTs are being tested, it is necessary to modify the tester ecosystem to suit the new DUTs. More specifically, different types of DUTs may require different hardware and / or software for testing. For example, one type of DUT may require a specific hardware interface for communicating with the test system (e.g., via a general serial bus) and / or a specific operating system (e.g., Linux® operating system) for running tests, while another type of DUT may require a different hardware interface (e.g., peripheral high-speed interconnect or Ethernet) and / or a different operating system (e.g., Windows® operating system). Changing the hardware and / or software required for testing increases the time required to set up the test and also increases costs.

[0008] Furthermore, different types of DUTs can have different physical dimensions (e.g., different sizes and / or shapes), which can pose a problem for conventional test systems. For example, the DUT is placed in a test interface board (TIB) for testing, and conventional test systems use TIBs with structures adapted to specific physical dimensions. Therefore, if DUTs with different physical dimensions are to be introduced into the test system, different TIBs designed to accommodate different physical dimensions must be swapped into the test system. This can also increase both the time required to set up the test and the testing cost.

[0009] 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®.

[0010] The number and types of tests (e.g., system-level testing [SLT], burn-in testing, functional testing, and scan testing), other factors mentioned above (e.g., different types of DUTs, different hardware interfaces, different operating systems), and the specific requirements of specialized tester ecosystems necessitate complex two-way communication between the test system and the hardware, "bare metal," and firmware of the DUT. Furthermore, most of this communication is conventionally managed by individual, isolated, and discrete software and hardware components, which is problematic for several reasons. Individual components often lead to integration difficulties. Ensuring seamless communication between different systems can be complex and time-consuming, requiring extensive custom development and continuous maintenance. When components operate in isolation, the lack of coordination can lead to inefficiencies. For example, repetitive tasks may be performed, or data may need to be manually transferred between systems, slowing down the overall test processing. Additionally, separated components make it difficult to debug the overall system in functional use cases. Separate systems can introduce more points of failure because inconsistencies and communication errors become more likely when information is transferred between multiple independent systems. As testing requirements evolve and the number of DUTs increases, scaling up the ecosystem of isolated components becomes challenging. New requirements or additions may necessitate further custom integration work, making it more difficult to adapt to changing needs. Maintaining multiple independent systems can also be costly. [Summary of the Invention]

[0011] Summary of the Invention

[0012] According to embodiments of the present invention, the above-mentioned problems and obstacles are overcome by introducing a test system, which includes a bridging component that acts as an overall test coordinator and performs various operations and functions across multiple and different platforms and multiple and different types of devices under test (DUTs). Embodiments of the present invention also introduce and include test assemblies with bridging components, and methods for use by or with the bridging components, test assemblies, and test system.

[0013] Generally, the supplier ecosystem (testing system) according to embodiments of the present invention includes a test assembly comprising multiple power distribution boards (PDBs) and multiple test interface boards (TIBs). The PDBs and TIBs can be mounted in a test rack. The DUT is connected to one or more TIBs (e.g., mounted on one or more TIBs), and the PDB controls the power to the TIBs, and has other functions further described herein. The testable end-user electronic device (DUT) can be virtually 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., gadgets with universal serial bus connections and gadgets with high-speed interconnect connections for peripheral components). The DUT can also be an individual component of such a device.

[0014] According to embodiments of the present invention, a "cross-platform bridge" is introduced into the vendor ecosystem (testing system). The cross-platform bridge connects the user-end ecosystem with the vendor ecosystem for testing equipment (e.g., full-size end-user devices). The cross-platform bridge allows seamless bidirectional communication between the user-end and the vendor ecosystem and is "hardware-independent". The cross-platform bridge acts as an overall coordinator, performing various functions across multiple platforms and supporting multiple DUT types and sizes.

[0015] More specifically, in embodiments, the cross-platform bridge includes multiple computing units (e.g., single-board computers, SBCs) on the PDB. Each computing unit / SBC can be connected to any actual number of DUTs on one or more TIBs, including DUTs of different types. The cross-platform bridge can determine the type of the DUT and its individual location on the TIB. 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 the DUT type, receive the test results, and provide the results to the user ecosystem. The test programs may include system-level testing, functional testing, and scan testing.

[0016] In an embodiment, the bridging component (cross-platform bridge) is implemented as a computing unit, which includes a first communication interface, a second communication interface, and a processor. The computing unit can receive test programs from one or more external systems (e.g., client systems or intermediate devices, such as proxy servers) communicatively coupled to the computing unit. These test programs are used to test one or more DUTs communicatively coupled to the computing unit. The computing unit can also transmit commands for executing the test programs to the DUTs, receive test results from the DUTs, and transmit the test results to appropriate external systems. Furthermore, the computing unit can determine the type of one or more DUTs, determine the location of the DUTs in the test system, associate individual test programs with the DUTs, and issue commands to the DUTs to execute the test programs using an operating system compatible with the type of the DUTs.

[0017] In an embodiment, a test assembly includes one or more test interface panels and one or more power distribution boards. Each test interface panel includes a connection interface. Each of the connection interfaces is configured to connect 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 connect to a respective set of one or more DUTs. Each of the one or more computing units can act as a cross-platform bridge as described above, and thus can determine the type of DUT in each set, determine the location of the DUT in each set in the test assembly, select an operating system compatible with the type of DUT in each set, and use the operating system to execute test programs on each DUT in each set.

[0018] In an embodiment, a test system includes a test assembly as described above. The test system also includes an intermediate device (e.g., a proxy server) providing remote access to the computing units. Each of one or more computing units is configured to connect to a separate set of one or more DUTs associated with a separate client system and can act as a cross-platform bridge as described above. That is, each of one or more computing units can execute multiple operating systems, identify the position of each DUT in a separate DUT set on one or more test panels, determine the type of DUT in a separate set, receive separate test programs from the client system via the intermediate device, execute the test programs using an operating system compatible with the type of DUT in a separate DUT set, and transmit the test results to the client system via the intermediate device.

[0019] According to embodiments of the present invention, methods (e.g., software) are also introduced for use by or in conjunction with bridging components, test assemblies and test systems.

[0020] In a method embodiment, the computing unit (e.g., SBC) receives a test program from an external system (e.g., a client system or intermediate device, such as a proxy server). The test program is used to test a DUT that is communicatively coupled to the computing unit and is on one or more TIBs. The TIBs are configured to connect to different types of devices with different body sizes. The computing unit determines the type of the DUT and the individual positions of each component in the DUT on the TIB. The computing unit selects an operating system compatible with the type of the DUT from a plurality of operating systems residing on and executable by the computing unit. The computing unit uses the selected operating system to issue commands to each DUT to execute the test program and executes the test program. The computing unit receives the test results and transmits the test results to the external system.

[0021] In a method embodiment, the computing unit detects the connection between the DUT in the test rack and one or more test interfaces (e.g., TIB 131 and 132). The DUT in the test rack may include different types of devices with different physical dimensions. The computing unit accesses a test program associated with a set of one or more DUTs from memory and maps the test program to the location of each DUT in the test rack. The operating system is selected from a plurality of operating systems residing in the memory of the computing unit, wherein the selected operating system is compatible with the type of device in the DUT set. The test program is then executed on each DUT in the DUT set using the operating system.

[0022] In a method embodiment, multiple test programs are received at a computing unit on a power distribution board in a test assembly of a test system. The test programs are used to test DUTs in one or more test racks of the test system or test assembly. Each test program includes separate commands for testing a separate set of DUTs. A first test program is mapped to the location of each DUT in a first set within the test assembly, wherein 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 the location of each DUT in a second set within the test assembly, wherein 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 in the first set using the first operating system; and the second test program is executed on each DUT in the second set using the second operating system. The second test program can be executed in parallel with the execution of the first test program. In one embodiment, the first and second test programs are executed in parallel by the same computing unit. The test results of the first DUT set are transmitted to the first user terminal system, and the test results of the second DUT set are transmitted to the second user terminal system.

[0023] Therefore, according to embodiments of the present invention, a cross-platform bridge (including one or more computing units) is provided, which operates as a general test coordinator and can perform various functions across multiple and different platforms and DUT types. Different types of DUTs can be tested without resetting the tester ecosystem. Furthermore, it simplifies bidirectional communication with the hardware, bare metal (e.g., devices or computer systems without a basic operating system or applications) and firmware of the DUT.

[0024] Other benefits provided in embodiments of the present invention include the ability to run different types of tests, such as, but not limited to, system-level testing (DLT), functional testing, scan testing, stress testing, connectivity testing, digital testing, and debugging operations, including testing for different communication and connectivity technologies and protocols (such as, but not limited to, Internet Protocol (IP), Transmission Control Protocol (TCP), Hypertext Transfer Protocol (HTTP), 4G and 5G cellular, WiFi, Bluetooth®, and Near Field Communication (NFC)) for digital circuit systems and radio frequency (RF) circuit systems. In embodiments, the power distribution board connected to the DUT is a discrete single-board computing unit that interfaces with each individual DUT. Thus, the disclosed test system provides a fully integrated ecosystem for directly automating the entire execution of any test program on the DUT. The slots in the TIB are combinable and therefore support different form factors. Therefore, the DUT can be easily replaced and can include any combination of devices with different form factors.

[0025] Other features, objectives and advantages of embodiments of the present invention are provided in the following detailed description, which is illustrated in various figures.

[0026] This summary is provided to introduce the selection of concepts further described below in the embodiments. This summary is neither intended to identify key or essential features of the claimed subject matter nor to limit the scope of the claimed subject matter.

Implementation Method

[0038] Detailed Description of Preferred Embodiments

[0039] Various embodiments of the present invention will now be described in detail with reference to the accompanying drawings, examples of which are illustrated. Although described in conjunction with these embodiments, it should be understood that this disclosure is not intended to limit the scope of these embodiments. Rather, this disclosure is intended to cover alternatives, modifications, and equivalents that may be included within the spirit and scope of this disclosure as defined by the appended claims. Furthermore, numerous specific details are set forth in the following detailed description of this disclosure to provide a thorough understanding of the disclosure. However, it should be understood that the invention may be practiced without such specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure the nature of the invention.

[0040] Some parts of the detailed description are presented according to procedures, steps, logical blocks, processes, and other symbolic representations of operations relating to data bits that can be executed on computer memory (e.g., Figures 7, 8, and 9). These descriptions and representations are used by those skilled in the art to most effectively convey the essence of their work to others skilled in the art. Programs, computer execution steps, logical blocks, processing programs, etc., are conceived here and generally as a self-consistent sequence of steps or instructions that produce the desired result. These steps are steps that require the manipulation of physical quantities. Usually, but not necessarily, these quantities are in the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated in a computer system or arithmetic unit. Primarily for common use, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, parameters, or the like.

[0041] However, it should be remembered that all such terms and similar terms are to be associated with the appropriate physical quantity and are merely convenient notations for application to such quantity. Unless otherwise specifically stated, it is obvious from the following discussion that the use of terms such as “receive,” “determine,” “select,” “store,” “transmit,” “download,” “publish,” “execute,” “provide,” “generate,” “send,” “upload,” “process,” “detect,” “access,” “map,” or similar terms throughout refers to the actions and processing procedures of a computer system or computing unit or similar electronic computing device that manipulates data represented as physical (electronic) quantities in the computer system’s registers and memory, and transforms that data into other data similarly represented as physical quantities in the computer system’s memory or registers or other such information storage, transmission, or display devices. As used herein, the term "communicatively coupled" indicates that elements (e.g., devices) are able to communicate with each other directly and / or indirectly through one or more intermediate elements using wired and / or wireless connections. As used herein, the term "connectivity" refers to the state or ability to connect to another element (e.g., device), such as a direct physical connection to another device or a connection that allows communication with another device.

[0042] The embodiments described herein can be discussed in the general context of computer-executable instructions residing on a form of computer-readable storage medium (such as a program module), which are executed by one or more computing units or other means. By way of example and not limitation, computer-readable storage media may include non-transitory computer storage media and communication media. Typically, a program module includes routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular type of abstract data. In various embodiments, the functionality of the program module may be combined or distributed as needed.

[0043] Computer storage media includes electrically and non-electrically oriented, removable and non-removable media used for storing information (such as computer-readable instructions, data structures, program modules or other data) implemented in any method or technology. Computer storage media includes, but is not limited to, random access memory, read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technologies, optical disc ROM (CD-ROM), digital versatile 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 that information.

[0044] Communication media may embody computer-executable instructions, data structures, and program modules, and includes any information delivery medium. By way of example and not limitation, communication media includes wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic waves, radio frequency (RF), infrared, and other wireless media). Any combination of the above may also be included within the scope of computer-readable media. Test systems and methods with cross-platform bridging components.

[0045] In summary, embodiments of the present invention provide a supplier ecosystem (testing system) capable of running a full suite of different types of tests on different types of Devices Under Test (DUTs). The testing system includes multiple Power Distribution Units (PDUs) and multiple Test Interface Boards (TIBs). The PDBs and TIBs can be mounted in a test rack. The DUT is connected to one or more TIBs (e.g., mounted on one or more TIBs), and the PDB controls the power to the TIBs, and has other functions further described below. The DUT can be virtually any type of device and can have different physical dimensions. The DUT can also be an individual component of such a device.

[0046] Embodiments of the present invention include a test system comprising a novel computing unit (which may be referred to herein as a "cross-platform bridge") connecting a user ecosystem to a vendor ecosystem for test devices ("devices under test") (e.g., full-size end-user devices). The cross-platform bridge may be mounted on a PDB, allowing seamless bidirectional communication between the user ecosystem and the vendor ecosystem, and is "hardware-independent" (e.g., designed to operate appropriately on and with various possible platforms or devices, regardless of the specific hardware used by the platform or device).

[0047] More specifically, in embodiments, the cross-platform bridge includes multiple (one or more) computing units (e.g., single-board computers) that can be connected to any actual number of DUTs (including different types of DUTs) on one or more TIBs. The DUTs can 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., gadgets with Universal Serial Bus (USB) connections and gadgets with high-speed interconnects for peripheral components). The DUTs can also be individual components of such devices.

[0048] The cross-platform bridge acts as a general coordinator for testing and communication, performing various functions across multiple and different platforms. It provides the execution context for testing, provides device isolation, specifies parameters such as voltage and current levels for components used to test the DUT, and supports multiple and different types of DUTs and different sizes (e.g., different numbers of DUTs). The cross-platform bridge can determine the type of the DUT and its individual location on the TIB. The cross-platform bridge can execute individual test programs on different sets of DUTs of the same type using software platforms (e.g., operating systems) compatible with the DUT type, receive test results, store results, post-process results, encapsulate results from DUTs of the same type, and provide results to the user ecosystem. These test programs may include, for example, system-level testing (SLT), functional testing, scan testing (e.g., via USB [Universal Serial Bus], PCIe [Peripheral Component Interconnect], or JTAG [Joint Test Action Group]), stress testing, connectivity testing, digital testing, and debugging operations, including testing for various communication and connectivity technologies and protocols (such as, but not limited to, IP, TCP, HTTP, 4G and 5G cellular, WiFi, Bluetooth®, and NFC) for digital and radio frequency (RF) circuit systems. Cross-platform bridges may also perform functions such as, but not limited to, running binary in the native operating system (e.g., the operating system used by the DUT), running characterization tests, running debugging tests, running production tests, and determining the minimum operating voltage of the DUT.

[0049] Therefore, the disclosed test system provides a fully integrated ecosystem for directly automating the entire execution of any test program on the DUT.

[0050] FIG1 is a block diagram showing selected components of a test system 100 according to an embodiment of the present invention. The test system 100 may include components other than those shown and described, and may also include a different number of the shown and described components.

[0051] In the embodiment of FIG1, the test system 100 includes a user (or customer) ecosystem and a supplier (or tester) ecosystem, which may be referred to herein as such. For example, the user ecosystem may include user systems 101 and 102, and the supplier ecosystem may include intermediate device 106 and test assembly 110.

[0052] Generally, client system 101 includes a computer system or network of computer systems belonging to a client entity that has a specific or similar interest in the DUT in some way. Client system 102 is a similar type of system or network. Client systems 101 and 102 can communicate with test system 100 via intermediate device 106. For example, client systems 101 and 102 can provide individual test programs to test system 100 via intermediate device 106. This allows the client to write its own custom commands and test programs for its individual DUTs. Furthermore, client systems 101 and 102 can receive test results from test system 100 for their individual DUTs via intermediate device 106. In addition, client systems 101 and 102 can be used to remotely participate in and / or manage the testing of their individual DUTs. For example, client systems 101 and 102 can analyze the test results of their individual DUTs and use those analysis results as feedback for the next stage of testing. Therefore, testing can be used on computer systems located anywhere in the world, and remote entities can perform tests just as they can physically access the test equipment.

[0053] In one embodiment, the intermediate device 106 is a proxy server. Client systems 101 and 102 can remotely access and log in to the intermediate device 106 using, for example, an IP address and some form of authentication (e.g., a password), and the intermediate device then forwards the remote login and grants secure access to a portion of the private network, including parts of the vendor ecosystem downstream of the intermediate device. Therefore, client systems 101 and 102 can be located anywhere in the world with internet access. In one embodiment, the intermediate device 106 is implemented using a rack-integrated computer system (RIC); however, the invention is not limited thereto.

[0054] In the embodiment of FIG1, the test assembly 110 includes a plurality of PDBs and a plurality of TIBs. The TIBs and PDBs may be mounted in a test rack (see, for example, FIG6A and FIG6B). In the example of FIG1, the test assembly 110 includes a PDB 120 and TIBs 131 and 132. The PDB 120 controls the power to the TIBs 131 and 132. Herein and in the following discussion, the test assembly 110 may include any actual number of the described hardware components. That is, for example, embodiments of the invention may include more than one PDB, more or less two TIBs, more or less four DUTs, etc.

[0055] The PDB 120 includes a plurality of connection interfaces configured to connect to the same number of processing units, represented by processing units 121 and 122. For example, processing units 121 and 122 can be inserted into slots on the PDB 120, but the invention is not limited thereto.

[0056] In one embodiment, each of the arithmetic units 121 and 122 is a single-board computer (SBC). The arithmetic units 121 and 122 are further described below with reference to FIG2. Generally, the arithmetic units 121 and 122 execute active control software, which executes test programs on the DUT by sending commands to the DUT.

[0057] Continuing with the example of Figure 1, each of TIBs 131 and 132 includes multiple connection interfaces configured to connect to the same number of DUTs, exemplified by DUTs 141, 142, 143, and 144. As will be further described herein, DUTs 141 to 144 may have different physical dimensions (e.g., different shapes or sizes). Thus, in one embodiment, the connection interfaces on TIBs 131 and 132 may be customized or configured to accommodate different physical dimensions (see also the discussion in Figure 4 below). DUTs 141 to 144 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). DUTs 141 to 144 can also be individual components of such devices.

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

[0059] FIG2 is a block diagram illustrating the selected elements of the arithmetic unit 200 according to an embodiment of the present invention. The arithmetic unit 200 is an example of the arithmetic units 121 and 122 of FIG1. ​​In the embodiment, the arithmetic unit 200 is implemented as a single-board computer (SBC) and includes a processor 202 and memory 204 coupled to the processor. The arithmetic unit 200 may include other components typical of known computer systems, such as display devices and user input devices; however, the arithmetic unit / SBC may perform its functions without such components.

[0060] The computing unit 200 of FIG2 also includes a first communication interface 211 operable for bidirectional communication with an external device. In an embodiment, the first communication interface 211 is operable for bidirectional communication with an intermediate device 106. Alternatively, the first communication interface 211 can be used to bypass the intermediate device 106 and communicate directly with a user terminal system. In one embodiment, the first communication interface 211 is an Ethernet driver. The first communication interface 211 can communicate with an external device via a wired or wireless connection (such as WiFi, Bluetooth®, and NFC), or may be capable of both wired and wireless communication. In one embodiment, the computing unit 200 has more than one communication interface operable for bidirectional communication with a second external device (e.g., the computer system 150 of FIG1 and / or other intermediate devices / proxy servers).

[0061] The processing unit 200 of FIG2 also includes a second communication interface 212, which is operable for bidirectional communication with TIBs 131 and 132 (FIG. 1) in general and specifically with one or more DUTs on the TIBs. For example, the second communication interface 212 may be communicatively coupled to any of DUTs 141 to 144, or coupled to more than one of DUTs 141 to 144 in any combination (refer to the examples in FIG. 5A, FIG. 5B, FIG. 5C and FIG. 5D below). In one embodiment, the second communication interface 212 is a USB universal connector; in another embodiment, it is an asynchronous receiver / transmitter (UART) connector; and in yet another embodiment, it is a PCIe connector. The second communication interface 212 may communicate with DUTs 141, 142, 143 and / or 144 via wired or wireless connection, or may be capable of both wired and wireless communication. Therefore, the computing unit 200 supports either or both of conductivity testing and over-the-air (OTA) testing. It also supports multiple transmit (Tx) and receive (Rx) power levels. Furthermore, it supports multiple-input and multiple-output (MIMO) antenna sharing. Testing can be performed on different frequency bands. In one embodiment, the computing unit 200 has more than one such communication interface, enabling it to communicate simultaneously (in parallel) with more than one DUT or a group of more than one DUT.

[0062] Due to its wired and wireless capabilities, the second communication interface 212 can be used for RF, cellular, and connectivity testing on DUTs 141, 142, 143, and / or 144. Cellular testing includes all low, medium, high, and ultra-high frequencies (e.g., approximately 400 MHz to approximately 7 GHz). The computing unit 200 can therefore test, for example, 4G and 5G cellular, WiFi, Bluetooth®, NFC, and Global Positioning System (GPS) functions and components on the DUTs.

[0063] The computing unit 200 is operable to execute different operating systems independently and in parallel. For example, the computing unit 200 may use virtualization technology or partition the memory 204 to run different operating system environments in parallel on the same hardware, but the present invention is not limited thereto. Operating systems that can be executed by the computing unit 200 include, but are not limited to, Linux® operating system, Windows® operating system, Android® operating system and Apple® operating system.

[0064] A single processing unit / SBC (e.g., processing unit 200) can communicate with and control the testing of a single DUT or multiple DUTs. The DUTs controlled by a single SBC can be of the same type or different types. As an example, the DUTs controlled by a single SBC may use different operating systems as discussed above, or may have different physical dimensions, or different characteristics (e.g., different operating voltages and currents), or may execute different test programs, or may have different features (e.g., one DUT may have a display device, and another DUT may not have a display device), or may have different components (e.g., different processors). Embodiments of the present invention are not limited to these examples.

[0065] The computing unit 200 may be further operable to perform other operations and functions in its role as an overall test coordinator. In an embodiment, 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 user intervention. Some examples of device types have been mentioned above.

[0066] Furthermore, in an embodiment, the processing unit 200 identifies the position of each DUT to be tested in the test assembly 110 (FIG. 1) before testing. Generally, the processing unit 200 identifies and enumerates the connected DUTs and constructs a map of the positions of the DUTs that can be used during testing. In one embodiment, the map may be displayed on a local computer (e.g., computer system 150) that specifically monitors the test assembly 110 or the overall test system 100.

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

[0068] In an embodiment, the arithmetic unit 200 of FIG2 provides an execution context for executing a test program to a set of DUTs to be tested using that test program, and also runs executable binary (such as, but not limited to, C#, Java®, and Python®) and low-level embedded code for executing DUT functionality during testing. In an embodiment, the arithmetic unit 200 runs binary and low-level embedded code on an operating system used by the set of DUTs.

[0069] In an embodiment, the arithmetic unit 200 sets individual voltage levels and individual current levels for testing components of the DUT. More specifically, for example, the arithmetic unit 200 may be connected to individual components on the DUT and set appropriate voltage and current levels for testing those components.

[0070] In one embodiment, the processing unit 200 receives test results from the DUT under test. In one embodiment, the processing unit 200 stores the test results. In another embodiment, the processing unit 200 performs post-processing on the test results. In yet another embodiment, the processing unit 200 processes the test results while the test is being executed. In such embodiments, the processing unit 200 can thus collect data, analyze data, and use the analysis results as feedback for the next stage of the test.

[0071] In this embodiment, the processing performed by the computing unit 200 includes real-time processing and post-processing of test results, and may include integrating and executing third-party frameworks. For example, an image of the phone being tested can be captured during testing, and an image processing algorithm (e.g., an artificial intelligence algorithm) can be deployed to transform or analyze the phone's behavior. As another example, during functional testing of the DUT, the thermal distribution and power distribution of the DUT can be determined and analyzed.

[0072] In this embodiment, the computing unit 200 compiles the test results of a set of DUTs associated with a specific user terminal system (e.g., user terminal system 101 in FIG1) into a data package, and sends the data package to that user terminal system directly via the first communication interface 211 or through the intermediate device 106. In other words, if a specific type of device is being tested for a customer, the test results of that type of device can be compiled, packaged, and transmitted to the customer by the computing unit 200.

[0073] Therefore, as described above, a single compute unit / SBC (e.g., compute unit 200) has the ability to provide seamless bidirectional communication between the user (or customer) ecosystem and the supplier (or tester) ecosystem. Two ecosystems can communicate seamlessly with each other without needing to fully understand the details of how the other ecosystem operates. Each compute unit / SBC also has the ability to communicate with and control different types of DUTs, thereby enabling simultaneous testing of multiple devices (e.g., different types of DUTs) without requiring a tester ecosystem dedicated to any particular type of device. Thus, the test system 100 provides a fully integrated ecosystem for directly automating the entire execution of any test program on the DUT. Therefore, each compute unit / SBC can be characterized and referred to as a cross-platform bridge or bridging component. Groups of such compute units / SBCs on the PDB can also be collectively characterized and referred to as cross-platform bridges or bridging components.

[0074] Figure 3 is a block diagram of an example of a power distribution board (e.g., PDB 120) according to an embodiment of the present invention. PDB 120 is connected to multiple processing units / SBCs, illustrated in the figure by SBCs 121 and 122. In one embodiment, a master controller 310 is also connected to PDB 120 and communicatively coupled to the processing units / SBCs. The master controller 310 manages and coordinates the execution of test programs via the multiple processing units / SBCs. For example, processing units / SBCs 121 and 122 can operate collaboratively to execute the same test program or different parts of the same test program across multiple DUTs under the control of the master controller 310.

[0075] Figure 4 is a block diagram of an example of a test interface panel (e.g., TIB 131) according to an embodiment of the present invention. In the example of Figure 4, TIB 131 includes a plurality of connection interfaces or slots, exemplified by connection interfaces 411 and 412. Each connection interface is configured for connection to a respective DUT, exemplified by DUTs 141 and 142. DUTs 141 and 142 may have different external dimensions (e.g., different shapes or sizes).

[0076] In one embodiment, each of the connection interfaces 411 and 412 includes a mechanical insert that is sized and shaped to fit the external dimensions of the respective DUT. For example, DUT 141 may be a smartphone and DUT 142 may be a tablet computer. In this case, connection interface 411 is sized and shaped to securely hold the smartphone in place, and connection interface 412 is sized and shaped to securely maintain the shape of the tablet computer.

[0077] In one embodiment, connection interfaces 411 and 412 can be removed from TIB 131 so that one connection interface can be replaced with another connection interface according to the appearance size of the DUT under test. For example, a connection interface pre-sized for a specific appearance size can be removed and replaced with a connection interface pre-sized for a different appearance size.

[0078] In another embodiment, the connection interfaces 411 and 412 are reconfigurable. For example, the sides of the connection interfaces can be moved or otherwise adjusted to form different sizes and shapes that match the external dimensions of the DUT.

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

[0080] FIG5A is a block diagram illustrating an example of a test setup for a test system 100 (FIG. 1) or test assembly 110 according to one embodiment of the present invention. In the example of FIG5A and in other examples herein, PDB 120 is shown having four operational units / SBCs 121, 122, 511, and 512, and TIB 131 is shown having four DUTs 141 to 144; however, the invention is not limited thereto, and PDB can be adapted to any actual number of operational units / SBCs, and TIB can be adapted to any actual number of DUTs. Operational units / SBCs 511 and 512 can be connected to other DUTs (not shown).

[0081] In the example of Figure 5A, there is a one-to-one configuration or mapping between the SBC and the DUT. Specifically, in this example, the processing unit / SBC 121 is connected only to (communicationally coupled to) the DUT 141, and the processing unit / SBC 122 is connected only to (communicationally coupled to) the DUT 142. In this example and other examples herein, the connection between the SBC / processing unit and the DUT can be a wired connection and / or a wireless connection.

[0082] In the example of Figure 5A, each arithmetic unit / SBC on PDB 120 can be connected to an individual DUT on TIB 131. Furthermore, one or more arithmetic units / SBCs on PDB 120 can be connected to an individual DUT on one TIB, while one or more other arithmetic units / SBCs on PDB 120 can be connected to an individual DUT on another TIB. Generally, the arithmetic units / SBCs on PDB 120 can be connected to an individual DUT on one or more TIBs. Therefore, in this example and the following examples, the test system 100 and test assembly 110 allow for considerable flexibility in configuring test settings.

[0083] Furthermore, in the example of Figure 5A and other examples herein, tests on individual DUTs or sets of DUTs can be performed in parallel. Therefore, many DUTs can be tested in parallel. This provides several benefits. For example, it increases the output of the test system. Different types of devices can be tested simultaneously; for example, laptops and telephones can be tested independently and simultaneously. Also, different test programs can be executed simultaneously on devices of the same type. For example, while debugging another telephone of the same type is being performed, functional testing of one type of telephone can be performed.

[0084] FIG. 5B is a block diagram illustrating another example of the test setup of the test system 100 (FIG. 1) or test assembly 110 according to one embodiment of the present invention. In the example of FIG. 5B, there is a one-to-one (N-to-one) configuration or mapping between the SBC and the DUT. Specifically, in this example, the arithmetic unit / SBC 121 is connected (communicationally coupled to) the DUTs 141 to 143. Although N is three in this example, the invention is not limited thereto; N can be any actual integer value. Other arithmetic units / SBCs on the PDB 120 can similarly be coupled to multiple DUTs or to a single DUT, as in the example of FIG. 5A.

[0085] In one embodiment, in this instance and in the following instances, when the processing unit / SBC 121 issues a test command, the command is automatically copied to all N DUTs. The processing unit / SBC 121 then waits for the test to complete on all N DUTs or waits for an assigned timeout. Once the test is complete and any results are received, the processing unit / SBC 121 can encapsulate those results and transmit them to the appropriate client ecosystem as previously described herein.

[0086] In the example of Figure 5B, the arithmetic unit / SBC 121 is connected to multiple DUTs on the TIB 131. As described above, the arithmetic unit / SBC 121 can execute different operating systems independently and in parallel, and therefore the DUTs connected to the arithmetic unit / SBC 121 can be of different types. Generally, each arithmetic unit / SBC on the PDB 120 can be connected to one or more DUTs and one or more types of DUTs. Therefore, as discussed above, the example of Figure 5B advantageously provides flexibility in configuring test setups.

[0087] Furthermore, although in the example of Figure 5B all DUTs are shown on the same TIB, the present invention is not limited thereto. That is, DUTs coupled / connected to the arithmetic unit / SBC 121 may be on different TIBs.

[0088] Figure 5C is a block diagram illustrating yet another example of the test setup of the test system 100 (Figure 1) or test assembly 110 according to one embodiment of the present invention. In the example of Figure 5C, there is a many-to-one (N-to-one) configuration or mapping between the SBC and the DUT. Specifically, the arithmetic unit / SBC 121 is connected (communicationally coupled to) DUTs 141, 142, and 144 on TIB 131 and DUTs 541, 542, and 543 on TIB 132. Although N is three in this example, the invention is not limited thereto; N can be any actual integer value. Other arithmetic units / SBCs on PDB 120 can similarly be coupled to multiple DUTs or to a single DUT, as in the example of Figure 5A.

[0089] As in the example of Figure 5B, the DUT connected to the arithmetic unit / SBC 121 can be of different types. Generally, each arithmetic unit / SBC on PDB 120 can be connected to one or more DUTs on one or more TIBs and one or more types of DUTs. Therefore, as discussed above, the example of Figure 5C provides advantageous flexibility in configuring test setups.

[0090] FIG. 5D is a block diagram illustrating yet another example of the test setup of the test system 100 (FIG. 1) or test assembly 110 according to one embodiment of the present invention. In the example of FIG. 5D, the arithmetic unit / SBC 121 is connected (communicationally coupled to) DUT 551, which is in turn connected (communicationally coupled to) DUT 552, which is also connected (communicationally coupled to) the arithmetic unit / SBC 121. This configuration represents a situation where the output of one DUT (e.g., DUT 551) affects the performance of another DUT (e.g., DUT 552).

[0091] For example, an autonomous vehicle may be equipped with a blind spot sensor. The output of the blind spot sensor can be provided to a second sensor, which determines whether the turn signal is activated or whether the vehicle is turning or changing lanes. If the turn signal is activated, the second sensor may react in one way (e.g., it may generate a warning of one type, thereby generating a vehicle response of one type); and if the vehicle is turning or changing lanes, the second sensor may react in a different way (e.g., it may generate a second type of warning, thereby generating a second type of vehicle response).

[0092] To test the scenario as described above, the results or outputs of test DUT 551 are sent to DUT 552. DUT 552 is tested based on the information received from DUT 551, and the results or outputs from DUT 552 are sent to the processing unit / SBC 121. More than two DUTs can be connected in any actual configuration to reflect different real-world application configurations as described above. Generally, the example in Figure 5D provides useful flexibility in configuring test setups.

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

[0094] In the example of FIG6A, test block 611 includes PDB 120 and TIB 131. As previously described herein, PDB 120 may include one or more operational units / SBCs, exemplified by operational unit / SBC 121, and TIB 131 may include one or more DUTs, exemplified by DUT 141.

[0095] In the example of FIG. 6B, the test rack 610 includes multiple slots or other components that support the test blocks inside the test rack. The test assembly 110 (FIGs 1 and 5A to 5D) may include other test racks adjacent to or close to 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 actual number of test blocks.

[0096] The processing unit / SBC in test block 611 can be communicatively coupled to one or more of the DUTs in TIB 131, and / or coupled to one or more DUTs in any other TIB or test block in test rack 610 or another test rack (not shown) of test assembly 110 (FIG. 1 and FIG. 5A to 5D) as previously described herein. Furthermore, the DUTs in test block 611 can be communicatively coupled to any processing unit / SBC on PDB 120, or coupled to any processing unit / SBC on any other PDB or test block in test rack 610 or another test rack of test assembly 110 as previously described herein. The same applies to test block 612.

[0097] Multiple (e.g., two or more) test blocks may be grouped together to form test block groups (e.g., test block groups 631 and 632 in FIG. 6B). Test blocks in a test block group may be adjacent to each other in the test rack 610, but the invention is not limited thereto. Individual test blocks and test block groups facilitate and implement device isolation and quadrant partitioning to ensure the integrity and security of the test. More specifically, test blocks or test block groups may be communicatively coupled to a single or separate user terminal system (e.g., user terminal system 101 or 102 in FIG. 1). Each user terminal system may communicate only with test blocks or test block groups that include the DUT belonging to that user terminal system. Therefore, a user-end system (e.g., user-end system 101) can provide individual test programs only to its own DUT and, for example, receive test results only from its own DUT; conversely, other user-end systems (e.g., user-end system 102) cannot communicate with the DUT belonging to user-end system 101 or receive test results from the DUT belonging to user-end system 101. Thus, individual test blocks or groups of test blocks can be tested independently and in isolation, and communication between the user-end system and its individual DUTs is secure.

[0098] FIG7 is a flowchart 700 of an example of a method performed by a computing unit (cross-platform bridge) in a test assembly (e.g., computing unit / SBC 121 in test assembly 110 of FIG1) according to an embodiment of the present invention. FIG8 is a flowchart 800 of an example of a method performed by a computing unit (cross-platform bridge) in a test assembly (e.g., computing unit / SBC 121 in test assembly 110 of FIG1) according to an embodiment of the present invention. FIG9 is a flowchart 900 of an example of a method performed by a test system (e.g., test system 100 of FIG1) according to an embodiment of the present invention. FIGS. 7 to 9 are discussed with reference to the figures discussed above. The methods described in the examples of FIGS. 7 to 9 can be performed using possible combinations of the elements described in the foregoing figures.

[0099] In block 702 of FIG7, a test program is received from an external system (e.g., from intermediate device 106 or user terminal system 101 or 102). The test program is used to test the DUT (e.g., one or more of DUTs 141 to 144) that are communicatively coupled to the computing unit and located on one or more TIBs (e.g., TIBs 131 and 132) in the test assembly 110. The TIBs are configured for connection to different types of devices with different body sizes.

[0100] In block 704, determine the type of DUT.

[0101] In block 706, determine the individual positions of each component in the DUT on the test panel.

[0102] In block 708, a working system compatible with the DUT type is selected from among multiple working systems residing on the computing unit and executable by the computing unit.

[0103] In block 710, commands for executing test programs are issued to each DUT using the selected operating system, and the test programs are executed. In this embodiment, a context for executing the test programs is also provided. In this embodiment, individual voltage and current levels for testing the components of each DUT are set using a computing device. In this embodiment, a third-party framework is integrated into the test program and executed during testing.

[0104] In block 712, the test results of the DUT are received. In an embodiment, the results are stored in the memory of the processing unit (e.g., memory 204 in FIG2). In an embodiment, the test results are processed. In an embodiment, the test results are analyzed while the test is being performed, and the analysis results are used as feedback for another stage of the test.

[0105] In block 714, the test results are transmitted to an external system. In this embodiment, a compiled data package including the test results is generated, and the data package is sent to the external system.

[0106] In block 802 of FIG8, the connection between the DUT (e.g., one or more of DUTs 141 to 144) and one or more test interfaces (e.g., TIBs 131 and 132) is detected. The DUT and the one or more test interfaces are in a test rack (e.g., test rack 610 of FIG6B) and communicatively coupled to the computing unit. The DUT in the test rack may include different types of devices with different external dimensions.

[0107] In block 804, a test program is accessed from the memory of the arithmetic unit (e.g., memory 204 in FIG2), wherein the test program is associated with a set of DUTs. The set may include one or more of DUTs 141 to 144.

[0108] In block 806, the test program is mapped to the location of each DUT in the test rack in the DUT set.

[0109] In block 808, an operating system is selected from a plurality of operating systems residing in the memory of the computing unit, wherein the selected operating system is compatible with the type of the device in the DUT set.

[0110] In block 810, the operating system is used to execute the test program on each DUT in the DUT set.

[0111] In block 902 of FIG9, multiple test programs are received at the computing unit (e.g., computing units 121 and 122 of FIG1) on the power distribution board (e.g., PDB 120) in the test assembly (e.g., test assembly 110) of the test system (e.g., test system 100). The test programs are used to test DUTs (e.g., DUTs 141 to 144) in one or more test racks (e.g., test rack 610 of FIG6B) in the test system or test assembly. Each test program includes specific commands for testing specific sets of DUTs.

[0112] In block 904, the first test program is mapped to the position of each DUT in the first DUT set in the test assembly, wherein the first DUT set is associated with the first test program and uses the first operating system.

[0113] In block 906, the second test program is mapped to the position of each DUT in the second DUT set in the test assembly, wherein the second DUT set is associated with the second test program and uses a second operating system different from the first operating system.

[0114] In some embodiments, the test assembly includes multiple test panels, a first DUT assembly is connected to a first test panel in the test assembly, and a second DUT assembly is connected to a second test panel in the test assembly. In other embodiments, the first DUT assembly and the second DUT assembly are connected to the same test panel. In some embodiments, the first test panel and the second test panel are located in the same test rack. In some embodiments, the first test panel and the second test panel are located in different test racks within the test assembly.

[0115] In block 908, the first test program is executed on each DUT in the first DUT set using the first operating system.

[0116] In block 910, a second test program is executed on each DUT in the second DUT set using a second operating system, wherein the execution of the second test program and the execution of the first test program are performed in parallel. In an embodiment, the first test program and the second test program are executed in parallel by the same computing unit.

[0117] In block 912, the results of testing the first DUT set are transmitted to the first user terminal system.

[0118] In block 914, the results of testing the second DUT set are transmitted to the second user terminal system.

[0119] In summary, the disclosed technology overcomes the limitations of conventional systems and methods by introducing a cross-platform bridge (e.g., one or more computing units) that acts as a general test coordinator and can perform various functions across multiple platforms (e.g., operating systems) and DUT types. Different types of DUTs can be tested without altering the tester ecosystem. Furthermore, it simplifies seamless bidirectional communication with the DUT's hardware, bare metal, and firmware. The cross-platform bridge is designed to operate appropriately on any possible platform or device, regardless of the specific hardware used by the platform or device.

[0120] At least one technical advantage of embodiments of the present invention is that a single computing unit / SBC or cross-platform bridge has the ability to provide seamless bidirectional communication between a user (or customer) ecosystem and a supplier (or tester) ecosystem. Two ecosystems can communicate seamlessly with each other without needing to fully understand the details of how the other ecosystem operates. Each computing unit / SBC also has the ability to communicate with and control different types of DUTs, thereby enabling the simultaneous testing of multiple devices without being dedicated to any particular type of device in the tester ecosystem. Each computing unit / SBC promotes the practice of device isolation to ensure the integrity and security of testing.

[0121] Other technical advantages provided by embodiments of the present invention include the ability to run the same tests on an SLT wafer running on a DUT, the ability to perform stress tests and connectivity tests in an integrated ecosystem, and the ability to perform advanced debugging test phases on a DUT while running digital and connectivity tests in parallel on multiple different devices.

[0122] Clause 1. In some embodiments, a computing unit includes: a first communication interface operable to receive from an external system communicatively coupled to the computing unit a plurality of test programs for testing a plurality of devices communicatively coupled to the computing unit; a second communication interface operable to: transmit commands for executing the plurality of test programs to the plurality of devices, and receive test results from the plurality of devices, wherein 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 coupled to the second communication interface, wherein the processor is operable to: determine a device type of a device set including one or more of the plurality of devices; associate one of the plurality of test programs with the device set; and issue commands for executing the test program to each device in the set using an operating system compatible with the device type.

[0123] Item 2. The computing unit as described in Item 1, wherein the plurality of devices are coupled to a test panel in a test rack and include different types of devices with different external dimensions.

[0124] Item 3. The arithmetic unit of any of items 1 and 2 is operable to determine a particular position of each device in the set on a test panel.

[0125] Item 4. The arithmetic unit of any of Items 1 to 3 is configured to execute multiple different operating systems.

[0126] Item 5. The computing unit of any one of items 1 to 4, wherein: the computing unit includes a single-board computer, the single-board computer includes a processor and memory, and is operable to use different communication protocols; the first communication interface includes an Ethernet driver; the second communication interface is selected from the group consisting of: a universal serial bus connector, an asynchronous receiver / transmitter connector, and a peripheral component high-speed interconnect connector; and the external system is a computer system selected from the group consisting of: a proxy server and a client system.

[0127] Clause 6. The arithmetic unit of any of Clauses 1 to 5 is operable to: generate a compiled data package containing the results of testing the devices in the set, and send the data package to the external system via the first communication interface.

[0128] Item 7. The operational unit of any of items 1 to 6, wherein the test is a type of test selected from the group consisting of: system-level test; functional test; and scan test.

[0129] Clause 8. The arithmetic unit of any of Clauses 1 to 7 further includes memory coupled to the processor, wherein the memory is operable to store the results of testing the devices in the set.

[0130] Item 9. An arithmetic unit as described in any of items 1 to 8, wherein the processor is further operable to process the results of testing the devices in the set.

[0131] Clause 10. In some embodiments, a test assembly includes: a test interface panel including a plurality of connection interfaces, wherein each of the plurality of connection interfaces is configured to connect to a plurality of devices under test (DUTs) for a particular DUT; and a power distribution board coupled to a plurality of computing units, wherein each of the plurality of computing units is configured to connect to a particular DUT set including one or more of the plurality of DUTs, and wherein each computing unit is operable to: determine a type of the DUTs in the particular DUT set; select one of a plurality of operating systems, wherein the operating system is compatible with the type of the DUTs in the particular DUT set; and execute a test program on each DUT in the particular DUT set using the operating system.

[0132] Item 11. The test assembly as described in Item 10, wherein each arithmetic unit is further operable to determine a position of each DUT in the respective DUT set on the test panel.

[0133] Item 12. The test assembly of any one of items 10 and 11, wherein each computing unit comprises: a single-board computer including a processor and memory and operable to use different communication protocols; a first communication interface coupled to the processor and including an Ethernet driver operable to communicate with an external system; and a second communication interface coupled to the processor and operable to communicate with the respective DUT assembly, and including a connector selected from the group consisting of: a universal serial bus connector, an asynchronous receiver / transmitter connector, and a peripheral component high-speed interconnect connector.

[0134] Item 13. The test assembly of any of items 10 to 12, wherein the plurality of DUTs connected to the test panel contain different types of devices with different external dimensions.

[0135] Clause 14. A test assembly as described in any of Clauses 10 to 13, wherein each arithmetic unit comprises: memory; a processor coupled to the memory and operable to generate a data package containing a compilation of the results of testing each DUT in the respective DUT set; and a communication interface coupled to the processor and operable to send the data package to an external system.

[0136] Clause 15. A test assembly as described in any of Clauses 10 to 13, wherein each arithmetic unit comprises: a memory operable to store the results of testing each DUT in the respective DUT set; and a processor coupled to the memory and operable to process the results of testing each DUT in the respective DUT set.

[0137] Clause 16. In some embodiments, a system includes: a test assembly comprising: a test interface panel including a plurality of connection interfaces, wherein each of the plurality of connection interfaces is configured to connect to one of a plurality of devices under test (DUTs); a plurality of computing units coupled to a power distribution board; and an intermediate device coupled to the test assembly and operable to provide remote access to the plurality of computing units; wherein one of the plurality of computing units includes a cross-platform bridge configured to connect to one or more of a user terminal system associated with a user terminal system. A set of DUTs, wherein the computing unit is operable to: execute multiple different operating systems; identify the position of each DUT in the set on the test panel; determine a type of DUT in the set; receive a test program from the client system via the intermediate device, the test program containing multiple commands for testing the set of DUTs; execute the test program using one of the multiple different operating systems, wherein the operating system is compatible with the type of DUT in the set of DUTs; and transmit the test results to the client system via the intermediate device.

[0138] Item 17. The system of Item 16, wherein the computing unit comprises: a single-board computer including a processor and memory and operable to use different communication protocols; a first communication interface coupled to the processor and including an Ethernet driver operable to communicate with the intermediate device; and a second communication interface coupled to the processor and including a connector selected from the group consisting of: a universal serial bus connector, an asynchronous receiver / transmitter connector, and a peripheral component high-speed interconnect connector.

[0139] Item 18. A system as described in any of items 16 and 17, wherein the plurality of DUTs connected to the test panel contain different types of devices with different external dimensions.

[0140] Item 19. The system of any one of items 16 to 18, wherein the test assembly further includes a test rack configured to support one or more test panels including the test panel, wherein each of the one or more test panels can be configured for different types of DUTs with different external dimensions.

[0141] Clause 20. The system of any one of Clauses 16 to 19, wherein the test assembly further includes a test rack, the test rack including the test interface panel and a second test interface panel, wherein the connection interfaces of the test interface panel are configured for connection to a first type of DUT, and wherein the connection interfaces of the second test interface panel are configured for connection to a second type of DUT, wherein the first type of DUT has a different external dimensions than the second type.

[0142] Clause 21. In some embodiments, a method performed by a computing unit in a test assembly includes: receiving from an external system operable to communicate with the computing unit a test program for testing a plurality of devices, the plurality of devices being communicatively coupled to the computing unit and coupled to one or more test panels of the test assembly; determining a device type of one of the plurality of devices; determining a separate location of each of the plurality of devices in the one or more test panels; selecting an operating system compatible with the device type, wherein the computing unit is configured to execute a plurality of different operating systems; issuing commands to the devices for executing the test program using the selected operating system; receiving the test results of the plurality of devices; and transmitting the test results to the external system.

[0143] Clause 22. The method of Clause 21, wherein the one or more test panels are assembled for connection to different types of devices with different external dimensions.

[0144] Clause 23. The method of any of Clauses 21 and 22 further includes providing a context for executing the test program.

[0145] Clause 24. The method of any one of Clauses 21 to 23, wherein: the computing unit comprises: a single-board computer including a processor and memory and operable to use different communication protocols; a first communication interface that receives the plurality of test programs from the external system and transmits the results of the tests to the external system; and a second communication interface that transmits the commands to the respective devices and receives the results of the tests; and the external system is a computer system selected from the group consisting of: a proxy server and a client system.

[0146] Clause 25. The method of any one of Clauses 21 to 24 further comprises: generating a compiled data package containing the results of the test of the respective devices; and sending the data package to the external system via the first communication interface.

[0147] Clause 26. The method of any one of Clauses 21 to 25 further comprises storing the results of the test of the respective devices in a memory of the arithmetic unit.

[0148] Clause 27. The method of any one of Clauses 21 to 26 further includes processing the results of the test of the respective devices.

[0149] Clause 28. The method of any of Clauses 21 to 27 further comprises setting a separate voltage level and a separate current level for testing components of the devices.

[0150] Clause 29. The method of any one of Clauses 21 to 28 further comprises: analyzing the test results while the test is being performed; and using the analysis results as feedback for the next stage of the test.

[0151] Item 30. The method of any of Items 21 to 29 further includes integrating a third-party framework into the test.

[0152] Clause 31. In some embodiments, a method performed by a computing unit connected to a power distribution board in a test assembly includes: detecting connections between a plurality of devices under test (DUTs) and one or more test interfaces, the DUTs and the one or more test interfaces being in a test rack and communicatively coupled to the computing unit; accessing a test program from a memory of the computing unit, wherein the test program is associated with a set of DUTs of the plurality of DUTs; mapping the test program to the location of each DUT in the set of DUTs in the test rack; selecting one of a plurality of operating systems residing in the memory of the computing unit, wherein the operating system is compatible with a type of device in the set of DUTs; and executing the test program on each DUT in the set of DUTs using the operating system.

[0153] Item 32. The method of Item 31, wherein the plurality of DUTs in the test rack include different types of devices with different external dimensions, and wherein the method further includes determining the type of the devices in the set of DUTs.

[0154] Clause 33. The method of any of Clauses 31 and 32 further includes providing a context for executing the test program.

[0155] Clause 34. The method of any one of Clauses 31 to 33 further comprises: receiving the result of testing the DUT set; and storing the result in the memory of the arithmetic unit.

[0156] Clause 35. The method of any one of Clauses 31 to 34 further comprises: receiving the results of testing the DUT set; and processing the results by a processor of one of the computer units.

[0157] Clause 36. In some embodiments, a method performed in a test system comprising a plurality of computing units coupled to a power distribution board includes: receiving, at the plurality of computing units, a plurality of test programs from a plurality of user terminal systems communicatively coupled to the test system, the plurality of test programs being used to test a plurality of devices under test (DUTs) in one or more test racks in a test assembly of the test system, wherein each of the plurality of test programs includes a respective command for testing a respective set of DUTs of the plurality of DUTs; mapping a first test program of the plurality of test programs to the location of each DUT in the first set of the plurality of DUTs in the test assembly, wherein the first set of DUTs is associated with the first test program and uses a first operating system; and mapping the plurality of test programs to the location of each DUT in the first set of the plurality of DUTs in the test assembly. A second test program in the test program is mapped to the position of each DUT in a second DUT set in the test assembly, wherein the second DUT set is associated with the second test program and uses a second operating system different from the first operating system; the first test program is executed on each DUT in the first DUT set using the first operating system; the second test program is executed on each DUT in the second DUT set using the second operating system, wherein the execution of the second test program and the execution of the first test program are performed in parallel; the results of testing the first DUT set are transmitted to a first user terminal system among the multiple user terminal systems; and the results of testing the second DUT set are transmitted to a second user terminal system among the multiple user terminal systems.

[0158] Clause 37. The method of Clause 36, wherein each of the plurality of computing units comprises: a single-board computer including a processor and memory and operable to use different communication protocols; a first communication interface coupled to the processor and operable to communicate with an intermediate device, the intermediate device being communicatively coupled to the first user terminal system and communicatively coupled to the second user terminal system; and a second communication interface coupled to the processor and operable to communicate with one or more of the plurality of DUTs.

[0159] Item 38. The method of any one of items 36 and 37, wherein the test assembly includes a plurality of test panels, wherein the first DUT set is connected to one of the plurality of test panels, and wherein the second DUT set is connected to one of the plurality of test panels, a second test panel.

[0160] Item 39. The method of items 36 and 37, wherein the test assembly includes a plurality of test panels, wherein the first DUT set and the second DUT set are connected to the same test panel among the plurality of test panels.

[0161] Item 40. The method of any one of items 36 to 39, wherein the first set of DUTs and the second set of DUTs are communicatively coupled to the same computing unit among the plurality of computing units coupled to the power distribution board, and wherein the execution of the first test program and the execution of the second test program are executed in parallel by the same computing unit.

[0162] Any and all combinations of any of the claimed elements described in any of the claims and / or any element described in this application are in any way within the scope of the invention and protection intended for this invention.

[0163] Various embodiments have been described for illustrative purposes, but such descriptions are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

[0164] The embodiments of the present invention may be embodied as a system, method, or computer program product. Therefore, the embodiments of this disclosure may be in the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware embodiments, all of which are generally referred to herein as a "module," "system," or "computer." Furthermore, any hardware and / or software technology, process, function, component, engine, module, or system described in this disclosure may be implemented as a circuit or a collection of circuits. Additionally, the embodiments of this disclosure may be in the form of a computer program product embodied in one or more computer-readable media having computer-readable code embodied thereon.

[0165] Any combination of one or more computer-readable media may be used. Computer-readable media may be computer-readable signal media or computer-readable storage media. Computer-readable storage media may be, for example, but not limited to: electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any suitable combination of the foregoing. More specific examples (not an exhaustive list) of computer-readable storage media will include: electrical connections having one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM, flash memory, optical fibers, CD-ROMs, DVDs, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, computer-readable storage media may be any tangible media that may contain or store programs for use by or in conjunction with an instruction execution system, device, or apparatus.

[0166] The present disclosure has been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that individual blocks in the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment to produce a machine. When executed by the processor of a computer or other programmable data processing equipment, the instructions enable the implementation of functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such processors may be, but are not limited to, general-purpose processors, special-purpose processors, special-application processors, or field-programmable gate arrays.

[0167] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in a block may appear in a different order than those mentioned in the figures. For example, depending on the functionality involved, two consecutively shown blocks may actually be executed substantially in parallel, or such blocks may sometimes be executed in reverse order. It should also be noted that each block and combination of blocks illustrated in block diagrams and / or flowcharts may be implemented by a special-purpose hardware-based system that performs a specified function or action or performs a combination of special-purpose hardware and computer instructions.

[0168] Although the foregoing content relates to embodiments of the disclosed content, other and additional embodiments of the disclosed content can be designed without departing from the basic scope of the disclosed content, and the scope of the disclosed content is determined by the following claims. [Simplified Explanation of the Diagram]

[0027] The accompanying drawings, which are incorporated in and form a part of this specification and in which similar numbers depict similar elements, illustrate embodiments of the invention and, together with the embodiments, serve to explain the principles of the disclosed invention. These drawings are not necessarily drawn to scale.

[0028] Figure 1 is a block diagram showing the selected components of a test system according to an embodiment of the present invention.

[0029] Figure 2 is a block diagram showing the selected elements of the arithmetic unit according to an embodiment of the present invention.

[0030] Figure 3 is a block diagram of an example of a power distribution board according to an embodiment of the present invention.

[0031] Figure 4 is a block diagram of an example of a test interface panel according to an embodiment of the present invention.

[0032] Figures 5A, 5B, 5C and 5D are block diagrams illustrating examples of different test settings according to embodiments of the present invention.

[0033] Figure 6A illustrates an example of a power distribution board and a test interface board according to an embodiment of the present invention.

[0034] Figure 6B illustrates an example of a selected element in a test rack according to an embodiment of the present invention.

[0035] Figure 7 is a flowchart of an example of a method executed by a computing unit according to an embodiment of the present invention.

[0036] Figure 8 is a flowchart of an example of a method executed by a computing unit in a test assembly according to an embodiment of the present invention.

[0037] Figure 9 is a flowchart of an example of a method performed by a test system according to an embodiment of the present invention.

Claims

1. A method executed by a computing unit in a test assembly, the method comprising: receiving, from an external system operable to communicate with the computing unit, a plurality of test programs for testing a plurality of devices, the plurality of devices being communicatively coupled to the computing unit and mounted on one or more test panels of the test assembly; determining a first device type and a second device type of the plurality of devices; determining a separate location of each device of the plurality of devices in the one or more test panels; mapping a first test program of the plurality of test programs to the separate location of each device of the first device type in the one or more test panels; mapping a second test program of the plurality of test programs to the separate location of each device of the second device type in the one or more test panels; selecting a first operating system compatible with the first device type and a second operating system compatible with the second device type, wherein the computing unit is configured to execute a plurality of different operating systems; The system uses a first operating system to issue commands to each device of the first device type to execute the first test program; uses a second operating system to issue commands to each device of the second device type to execute the second test program; receives the test results from the plurality of devices; and transmits the test results to the external system.

2. The method of claim 1, wherein the one or more test panels are assembled for connection to different types of devices with different external dimensions.

3. The method of claim 1, further comprising providing a context for executing at least one of the first test program and the second test program.

4. As in request item 1, where: The computing unit includes: a single-board computer including a processor and memory, and operable to use different communication protocols; a first communication interface that receives the plurality of test programs from the external system and transmits the test results to the external system; and a second communication interface that transmits the commands to the respective devices and receives the test results; and the external system is a computer system selected from the group consisting of: a proxy server and a client system.

5. The method of claim 4, further comprising: generating a compiled data package containing the results of the test of the respective devices; and sending the data package to the external system via the first communication interface.

6. The method of claim 1, further comprising storing the results of the test of each device in a memory of the arithmetic unit.

7. The method of claim 1, further comprising processing the results of the test of each device.

8. The method of claim 1, further comprising setting a separate voltage level and a separate current level for testing the components of the devices.

9. The method of request item 1 further includes: analyzing the test results while the test is being executed; and using the analyzed results as feedback for the next stage of the test.

10. The method of request item 1 further includes integrating a third-party framework into the test.

11. A method performed by a computing unit connected to a power distribution board in a test assembly, the method comprising: detecting connections between a plurality of devices under test (DUTs) and one or more test panels, the DUTs and the one or more test panels being located in a test rack and communicatively coupled to the computing unit, wherein the DUTs are mounted on the one or more test panels; accessing a first test program and a second test program from a memory of the computing unit, wherein the first test program is associated with a first DUT set of the plurality of DUTs, and the second test program is associated with a second DUT set of the plurality of DUTs; determining the positions of the DUTs in the first DUT set and the second DUT set in the test rack; mapping the first test program to the positions of the DUTs in the first DUT set in the test rack; and mapping the second test program to the positions of the DUTs in the second DUT set in the test rack. Select one first operating system and one second operating system from among a plurality of operating systems residing in the memory of the computing unit, wherein the first operating system is compatible with a first type of device in the first DUT set, and wherein the second operating system is compatible with a second type of device in the second DUT set; execute the first test program on each DUT in the first DUT set using the first operating system; and execute the second test program on each DUT in the second DUT set using the second operating system.

12. The method of claim 11, wherein the plurality of DUTs in the test rack include different types of devices with different external dimensions, and wherein the method further includes determining the type of the devices in the first set of DUTs and the second set of DUTs.

13. The method of claim 11, further comprising providing a context for executing at least one of the first test program and the second test program.

14. The method of claim 11, further comprising: receiving the results of testing the first DUT set and the second DUT set; and storing the results in the memory of the arithmetic unit.

15. The method of claim 11, further comprising: receiving the results of testing the first DUT set and the second DUT set; and processing the results by a processor of one of the computer units.

16. A method of execution in a test system, the test system comprising a plurality of computing units coupled to a power distribution board, the method comprising: receiving, at the plurality of computing units, a plurality of test programs from the plurality of user terminal systems communicatively coupled to the test system, the plurality of test programs being used to test a plurality of devices under test (DUTs) mounted on a plurality of test panels in one or more test racks in a test assembly of the test system, wherein each of the plurality of test programs includes a respective command for testing a respective set of DUTs of the plurality of DUTs; determining a position of each DUT in a first set of the plurality of DUTs in the test assembly, wherein the first set of DUTs uses a first operating system; determining a position of each DUT in a second set of the plurality of DUTs in the test assembly, wherein the second set of DUTs uses a second operating system different from the first operating system; The test program maps one of the plurality of test programs to the location of each DUT in the first DUT set within the test assembly, wherein the first DUT set is associated with the first test program; the test program maps one of the plurality of test programs to the location of each DUT in the second DUT set within the test assembly, wherein the second DUT set is associated with the second test program; the test program is executed on each DUT in the first DUT set using a first operating system; the test program is executed on each DUT in the second DUT set using a second operating system, wherein the execution of the second test program and the execution of the first test program are performed in parallel; the test results of the first DUT set are transmitted to one of the plurality of user terminal systems, namely, a first user terminal system; and the test results of the second DUT set are transmitted to one of the plurality of user terminal systems, namely, a second user terminal system.

17. The method of claim 16, wherein each of the plurality of computing units comprises: a single-board computer including a processor and memory, and operable to use different communication protocols; a first communication interface coupled to the processor and operable to communicate with an intermediate device, the intermediate device being communicatively coupled to the first user terminal system and communicatively coupled to the second user terminal system; and a second communication interface coupled to the processor and operable to communicate with one or more of the plurality of DUTs.

18. The method of claim 16, wherein the test assembly includes the plurality of test panels, wherein the first DUT set is connected to one of the plurality of test panels, and wherein the second DUT set is connected to one of the plurality of test panels, a second test panel.

19. The method of claim 16, wherein the test assembly includes the plurality of test panels, wherein the first DUT set and the second DUT set are connected to the same test panel among the plurality of test panels.

20. The method of claim 16, wherein the first set of DUTs and the second set of DUTs are communicatively coupled to the same computing unit among the plurality of computing units coupled to the power distribution board, and wherein the execution of the first test program and the execution of the second test program are executed in parallel by the same computing unit.

Images