Adaptable hardware interface for testing

Abstract

Systems, methods, and other embodiments described herein relate to improving testing of electronic devices using an adaptable interface.SOLUTION: In one embodiment, a method includes receiving, in an interface device, an initialization request to access a testing device, wherein the testing device is connected with a bridge at the interface device via a connector pin. The method includes obtaining, from a memory in the interface device, configuration information for the testing device including at least a mapping of connector pins to bridges. The method includes providing configuration information to facilitate mediation of communications with a testing device.SELECTED DRAWING: Figure 2B

Description

[Technical Field]

[0001] The subject matter described herein relates generally to testing of electronic devices, and more particularly to an adaptable interface that provides easy access to devices under test in a configurable manner. [Background technology]

[0002] Developers develop software for new devices and implement test benches to provide a controlled environment for testing that the new devices function as expected. Typically, test benches are built on a per-device basis. As an example, in the context of vehicle electronic control units (ECUs), a test bench may include custom wiring harnesses that connect various different devices to each other while also providing additional connections for testing purposes. However, the unique nature of the test bench requires institutional knowledge to use the test bench effectively, thus limiting the ability to share the bench among multiple developers and complicating access overall. Furthermore, as the complexity of the device or device's mechanism under test increases and / or the test requirements increase, the wiring harness also becomes more complex and difficult to build and maintain. Furthermore, increased complexity also leads to increased costs for non-reusable test mechanisms, thereby leading to additional waste. Summary of the Invention

[0003] Exemplary systems and methods relate to testing electronic devices using an adaptable interface. As previously discussed, test benches can be complex to implement due to various considerations, including the complexity of the device or devices being tested. This leads to increased costs and waste because the test benches are complex to implement and typically not reusable. Accordingly, in at least one approach, an inventive system is disclosed that provides an adaptable interface and associated logic to improve testing of electronic devices. For example, in at least one aspect, an interface device includes a controller, memory, bridges, and connectors to support communication with the device under test (i.e., the electronic device). The electronic device can take many different forms, including a module with multiple die packages, a single die package, and the like. As described herein, the electronic device is generally an electronic control unit such as may be used in a vehicle. While the present disclosure focuses on the context of a vehicle, it should be understood that the devices, systems, and methods of the present disclosure are applicable to other contexts.

[0004] In either case, consider that electronic devices, e.g., an ECU or multiple ECUs, are generally connected using complex wiring harnesses when installed in a vehicle. The wiring harness may include a connector for each separate ECU with wiring between them. Furthermore, within the context of testing, the wiring harness may also be implemented to include a diagnostic connector that provides diagnostic signals. However, as mentioned above, it is complex to custom-design a unique wiring harness for each different configuration of electronic devices that may need to be tested. Therefore, an interface device solves this problem by using bridges to connect with multiple electronic devices under test, e.g., multiple different ECUs. The bridges connect to each electronic device via connector pins, which may be separate pins on the device or located on a mating connector. The connector pins connect the bridges to explicit connector ports associated with the electronic device (e.g., ECU) being tested or directly to pins on a die package or other electronic device (e.g., a sensor).

[0005] As a result, the connector pins can be unique to a particular electronic device, instead of a more complex harness that is not modifiable to different mechanisms. Because the connector pins from the bridge to the electronic device are unique in each instance, the interface further includes memory, which may be an EEPROM or similar type of non-volatile memory, that stores configuration information about the electronic device under test and other devices connected to the bridge via the connector pins. The content of the configuration information may vary depending on the implementation, but generally includes descriptive data identifying the electronic device (e.g., serial number or other identifier, version number, etc.) and a mapping of the connector pins. The mapping identifies the correlation of the pins of the electronic device to the ports of the bridge to which the pins are connected and exposed for communication. Thus, the controller mediates access to the electronic device by communicating the configuration information so that a test server or other test management device may access the electronic device.

[0006] In various mechanisms, the interface devices communicate with edge services and / or cloud services that function to simplify access to devices under test. An edge service may aggregate configuration information from multiple different interface devices that connect to different electronic devices. Thus, the edge service may connect to the interface devices through an Ethernet switch or other communication network and function to obtain configuration information for the set of electronic devices associated with the different interface devices. As a result, the edge service generates a mapping of the set of electronic devices and the associated connections provided through their respective bridges. The test system may then use the edge service to create a virtual wire harness through the use of the mapping to emulate the connections between the different electronic devices. That is, the edge service may provide connections between the different electronic devices through the interface devices in a manner similar to that done using a physical wire harness, but without the complexity and waste of implementing a wire harness. Furthermore, a cloud service may further aggregate the mappings from multiple edge services. The cloud service may then provide access to remote clients, thereby improving access to the devices, in addition to enabling additional functionality, such as more complex virtual harnesses between separate edge services, reservations, data analysis, and the like. In this manner, the techniques of the present disclosure can improve testing of electronic devices by avoiding complex, expensive, and potentially wasteful physical harnesses for testing.

[0007] In one embodiment, an interface system is disclosed. The interface system includes one or more processors and a memory communicatively connected to the one or more processors. The memory stores a control module including instructions that, when executed by the one or more processors, cause the one or more processors to receive, within an interface device, an initialization request to access a test device, the test device connected to a bridge at the interface device via a connector pin. The control module includes instructions for retrieving, from the memory within the interface device, configuration information regarding the test device, including at least a mapping of the connector pins to the bridge. The control module includes instructions for providing the configuration information to facilitate mediating communications with the test device.

[0008] In one embodiment, a non-transitory computer-readable medium is disclosed that includes instructions that, when executed by one or more processors, cause the one or more processors to perform one or more functions. The instructions include instructions for receiving, within an interface device, an initialization request to access a test device, the test device coupled to a bridge at the interface device via connector pins. The instructions include instructions for retrieving configuration information for the test device from a memory within the interface device, the configuration information including at least a mapping of the connector pins to the bridge. The instructions include instructions for providing the configuration information to facilitate mediating communications with the test device.

[0009] In one embodiment, a method is disclosed. In one embodiment, the method includes receiving, in an interface device, an initialization request to access a test device, the test device connected to a bridge at the interface device via connector pins. The method includes retrieving configuration information for the test device from a memory in the interface device, the configuration information including at least a mapping of the connector pins to the bridge. The method includes providing the configuration information to facilitate mediating communications with the test device. [Brief explanation of the drawings]

[0010] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be understood that the boundaries of elements shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent one embodiment of the boundaries. In some embodiments, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component, and vice versa. Additionally, elements may not be drawn to scale.

[0011] [Figure 1] FIG. 1 illustrates one embodiment of an interface system associated with an adaptable platform for testing electronic devices. [Figure 2A] FIG. 2A illustrates one embodiment of an interface device and a connection device. [Figure 2B] FIG. 2B illustrates an embodiment of the interface device of FIG. 2A with additional details shown. [Figure 3] FIG. 3 shows a flow chart of the communication between the interface device and the test service. [Figure 4] FIG. 4 is a flowchart illustrating a method associated with using an interface device to mediate communications with a device under test. [Figure 5] FIG. 5 illustrates one configuration of an edge service that includes multiple interfacing devices. [Figure 6] FIG. 6 illustrates one configuration of a cloud-based service that utilizes an interface device to provide emulation of a physical wire harness. [Figure 7] FIG. 7 is a flowchart illustrating a method associated with emulating a wire harness. [Figure 8]FIG. 8 illustrates one arrangement of a rack system that houses multiple networks of interface devices. DETAILED DESCRIPTION OF THE INVENTION

[0012] Systems, methods, and other embodiments associated with testing electronic devices using adaptable interfaces are disclosed. As previously discussed, test benches can be complex to implement due to various considerations, including the complexity of the device being tested. This leads to increased costs and waste because the test benches are complex to implement, specific to a particular instance, and therefore not reusable. By way of example, within the context of a vehicle, a wiring harness may interface with a dozen or more electronic control units. Each electronic control unit (ECU) undergoes development and testing to implement a specific function in the vehicle in the manner desired by the developer. Thus, each different configuration of systems within the vehicle under development, and each separate iteration of different ECUs that may be selected, requires a new wiring harness to be manually manufactured. As a result, the ability to iterate on a design when developing a new platform can be costly, thereby potentially limiting development.

[0013] Thus, in at least one approach, an inventive system is disclosed that provides an adaptable interface and associated logic to improve testing of electronic devices. For example, in at least one aspect, an interface device comprises a controller, memory, bridges, and connectors to support communication with a device under test (i.e., an electronic device, also referred to herein as a test device). The electronic device may take many different forms, including a module having multiple die packages, a single die package, a system-on-chip (SoC), and the like. As described herein, the electronic device is generally an electronic control unit (ECU), such as may be used in a vehicle. While this disclosure focuses on the vehicle context, it should be understood that the devices, systems, and methods of this disclosure are applicable to other contexts, and the described context should not be construed as limiting.

[0014] In either case, consider that electronic devices, e.g., an ECU or multiple ECUs, are generally connected using complex wiring harnesses when installed in a vehicle. The wiring harness may include a connector for each separate ECU with wiring between them. Additionally, within the context of testing, the wiring harness may also be implemented to include a diagnostic connector that provides diagnostic signals. However, as mentioned above, it is complex to custom-design a unique wiring harness for each different configuration of electronic devices that may need to be tested. Therefore, the interface device solves this problem by using bridges to connect with multiple electronic devices under test, e.g., multiple different ECUs. The bridges connect to each electronic device via connector pins. The connector pins connect the bridge to an explicit connector port associated with the electronic device (e.g., ECU) being tested or directly to pins on a die package or other electronic device (e.g., a sensor).

[0015] As a result, the connector pins can be unique to a particular electronic device, instead of a more complex harness that is not modifiable for different mechanisms. Because the connector pins from the bridge to the electronic device are unique in each instance, the interface device further includes memory, which may be an EEPROM or similar type of non-volatile memory, that stores configuration information about the electronic device under test and other devices connected to the bridge through other connector pins. The content of the configuration information can vary depending on the implementation, but generally includes descriptive data identifying the electronic device (e.g., serial number or other identifier, version number, etc.) and a mapping of the connector pins. The mapping identifies the correlation of the pins of the electronic device to the ports of the bridge to which the pins are connected and exposed for communication. Thus, the controller mediates access to the electronic device by communicating the configuration information so that a test server or other test management device can access the electronic device through the bridge by using the mapping.

[0016] In various further mechanisms, the interface device communicates with an edge service and / or a cloud service. The edge service may function to aggregate configuration information from multiple different interface devices that connect to different electronic devices in a network connection with the interface device. Thus, the edge service may connect to the interface device through an Ethernet switch or communication network and function to obtain configuration information regarding a set of electronic devices associated with the different interface devices. As a result, the edge service generates a mapping of the set of electronic devices and the associated connections provided through their respective bridges. The test system may then use the edge service to create a virtual wire harness through the use of the mapping to emulate the connections between the different electronic devices. That is, the edge service may provide connections for the different electronic devices through the interface device in a manner similar to that done using a physical wire harness, but without the complexity and waste of implementing a wire harness.

[0017] Additionally, cloud services may further aggregate mappings from multiple edge services to provide additional functionality. Cloud services may provide remote client access, as well as enable additional functionality, such as more complex virtual harnesses between separate edge services, reservations for scheduling tests between different entities, data analysis, etc. In this manner, the techniques of the present disclosure may improve testing of electronic devices by avoiding complex, expensive, and potentially wasteful physical harnesses for testing.

[0018] Referring to FIG. 1 , one embodiment of an interface system 100 is shown. The interface system 100 is shown as including a processor 110, which may be incorporated within the interface system 100 or associated with a separate computing device, such as a server or cloud computing system. Thus, the processor 110 may be part of the interface system 100, or the interface system 100 may access the processor 110 through a data bus or another communication path. In one embodiment, the interface system 100 includes a memory 130 that stores a control module 120. The memory 130 may be a random access memory (RAM), a read-only memory (ROM), a hard disk drive, flash memory, or another suitable memory that stores the module 120. The module 120 may be, for example, computer-readable instructions that, when executed by the processor 110, cause the processor 110 to perform various functions disclosed herein. In an alternative arrangement, the module 120 may be separate from the memory 130 and may comprise, for example, hardware elements (e.g., an arrangement of logic gates). Thus, module 120 may alternatively be an ASIC, a hardware-based controller, an arrangement of logic gates, or another hardware-based solution.

[0019] 1 is an abstract form of interface system 100 that may be implemented as part of an interface device, an edge service, and / or a cloud computing system. It should be understood that the functionality described in connection with interface system 100 may be maintained entirely within a single device, e.g., the interface device itself, or may be distributed among multiple different devices, e.g., an interface device, a computing element acting as an edge service, a computing element acting as a cloud service, etc. Accordingly, the particular mechanisms described in connection with FIG. 1 are not intended to be limiting, but rather as examples of how particular functionality described herein may be performed in connection with a computing device.

[0020] Referring to FIG. 2A , an example of an interface device 200 (also referred to herein as a hardware interface (HWI)) is shown. As shown, the interface device 200 interfaces with a device under test (DUT) 205. The DUT 205 may generally be any electronic device being tested, such as an ECU or other electronic module. The interface device 200 interfaces with the DUT 205 via connector pins that are unique to the DUT 205. As shown in this example, the connector pins include three main connections, each of which may comprise multiple separate wires. In particular, the DUT 205 is connected via a control area connection (CAN), a 12V I / O, and a power line. These separate portions of the connector pins interface with a CAN port, an IGN port, and a power input, respectively. Thus, as can be seen from this example, the connector pins for each separate DUT may be unique to that DUT and, therefore, implemented on a per-device basis, at least in one mechanism. 2A as connecting with a single DUT 205, in various arrangements, interface device 200 may connect multiple separate DUTs. The number of devices to which interface device 200 connects is generally limited only by the attributes of the hardware contained within interface device 200 itself, such as a communications bridge that may have a certain number of ports to connect to.

[0021] Separately, in the illustrated example, interface device 200 couples with computing device 210. In one or more configurations, computing device 210 is a server, desktop computer, laptop, or another device capable of executing instructions to test DUT 205 and communicate through interface device 200. Computing device 210 executes test services 215 that include instructions for testing DUT 205. For example, test services 215 may include instructions to provide automated testing and / or provide a manual interface to the DUT for manual testing. Testing may take different forms depending on the particular application, but may include diagnostic testing, development and debugging of software used in DUT 205, etc.

[0022] In either case, test service 215 uses interface library 220 to provide an interface with interface device 200 and DUT 205. That is, interface library 220 may form an application program interface (API) or other software library that provides functionality to facilitate communication between computing device 210 and interface device 200 over an Ethernet connection or other electronic communications link. For further details of interface device 200, consider FIG. 2B, which illustrates additional components related to the example interface device 200 of FIG. 2A. As shown, interface device 200 includes memory 225, a management controller 230, a transceiver 235, and a bridge 240.

[0023] The transceiver 235 provides communication with the computing device 210 over an Ethernet connection or other communication link and may also route communications within the interfacing device 200 itself. For example, in response to a request provided by the computing device 210 via the interface library 220, the transceiver 235 may route communications to the managing controller 230 or directly to the bridge 240. The managing controller 230 may be an ASIC, logic, or other programmable processing device that processes initialization requests from the computing device 210 or another external device. For example, the managing controller 230 may receive an initialization request for information regarding one or more DUTs connected to the interfacing device 200. Generally, the interfacing device 200 stores configuration information for each DUT connected to the interfacing device 200. The interfacing device 200 may store the configuration information in the memory 225. The memory 225 may be, for example, an EEPROM or other non-volatile memory.

[0024] The configuration information stored in memory 225 includes information about the DUT 205 and the connector pins connecting the DUT 205 to the bridge 240. The information about the DUT 205 may include a device identifier, a version number, and other attributes (e.g., device specifications, such as memory and processing power). The connector pin information includes a mapping or list of how the pins of the DUT 205 are connected to the bridge 240. Thus, the pin information correlates the pins to the ports of the bridge 240 so that a requesting device (i.e., the computing device 210) can generate the mapping for subsequent powering, control, and otherwise communicating with the DUT 205. Thus, the test service 215, using the interface device 200, constructs a mapping that provides routing of signals generated by the test service 215 during execution of a test program to the appropriate pins of the DUT 205. Generally, the mapping defines the port associated with the bridge 240 to communicate signals at specific pins of the DUT 205. In this manner, the interface device 200 exposes the DUT 205 for interaction with external devices.

[0025] 3 , an example 300 of communication between test service 215, interface library 220, and interfacing device 200 is depicted. For additional context, in at least one mechanism, test service 215 is an automated test program that provides a defined set of inputs to DUT 205 while recording the responses to characterize the performance of DUT 205 (e.g., whether DUT 205 is operating as expected). In a further mechanism, test service 215 may be a development environment that generates software code and loads it into DUT 205 for execution. In yet a further mechanism, test service 215 is a manual test interface that allows a user to select and provide inputs directly to DUT 205. In yet a further mechanism, test service 215 is a client that interfaces with external requests from remote applications. For example, test service 215 may interface with an edge service, a cloud-based service, or another entity to provide access to DUT 205 or other attached DUTs of interfacing device 200.

[0026] In either case, at 305, test service 215 initiates communication with interfacing device 200. To provide the communication in an appropriate manner, interface library 220, which may be implemented as instructions executed as part of test service 215, processes the request into a query to the interfacing device, as shown at 310. In response to the query, interfacing device 200, via managing controller 230, functions to retrieve configuration information from memory 225 and communicate the configuration information back to the interface library, which is shown as a multi-step process at 315. Although shown as being retrieved in multiple steps, in various mechanisms, interfacing device 200 may provide the contents of the configuration information in a single communication or in multiple communications, depending, for example, on buffer size and / or other hardware constraints.

[0027] The interface library 220 then functions to generate a mapping of pins on the interface device 200 and the connected DUT 205 so that the interface library 220 can translate requests from the test service 215 and communicate the requests on the appropriate port of the bridge 240. In either case, once the interface library 220 has functioned to initialize the mapping, which may be implemented as a list, table, or another data structure correlating ports with pins, the test service 215 can query the interface library 220 for information about the DUT 205, such as an identifier, version number, and connection pins / interfaces available on the DUT 205, as shown at 320. While a single DUT 205 is described, it should be understood that in further mechanisms, the information returned from the interface device 200 may include multiple DUTs. Thus, the interface library 220 may then function to provide information about multiple separate DUTs. FIG. 3 further illustrates how the test service 215 proceeds to interact with the DUT 205 via the interface device 200. The communications shown generally include powering the DUT 205, communicating with the DUT 205, and obtaining diagnostic information such as status reports from the DUT 205 via connection pins.

[0028] Additional aspects of using an interface device to facilitate communication for testing are described in connection with FIG. 4. FIG. 4 illustrates a flowchart of a method 400 associated with adaptively interfacing with a device under test (DUT). Method 400 is described in terms of interface system 100 of FIG. 1 with further reference to interface device 200 of FIGS. 2A-2B. While method 400 is described in combination with the elements shown, it should be understood that method 400 is not limited to implementation within interface system 100, but is an example of a system in which method 400 may be implemented.

[0029] At 410, control module 120 monitors requests from devices connected to interfacing device 200. For example, interfacing device 200 may connect directly to another device or to a network through which multiple different devices may communicate. In various mechanisms, interfacing device 200 connects to the network or directly to other devices via an Ethernet cable or other suitable communication link. In either case, control module 120, which may be implemented at least in part as managing controller 230, monitors the communications and identifies or otherwise distinguishes between different communications. In one approach, control module 120 monitors a particular flag in the communication or otherwise parses the communication to determine whether the communication is an initial configuration request to access a test device (i.e., DUT) connected to bridge 240. If the communication is an initial configuration request, control module 120 proceeds to obtain configuration information, as described at 420. If not, control module 120 continues to monitor the communication.

[0030] At 420, control module 120 retrieves configuration information from memory within interfacing device 200. As previously mentioned, memory 225 stores configuration information for devices connected to bridge 240 of interfacing device 200. Thus, memory 225 may store different selections of configuration information depending on how multiple devices are connected to the interfacing device. Thus, control module 120 may retrieve configuration information for all of the attached devices or for the devices specified in the request, depending on the implementation. Thus, control module 120 may parse the request to identify attributes of the request, including the DUT for which information is requested, generally. Of course, in an alternative mechanism, control module 120 may simply retrieve information for all DUTs for which configuration information is present in memory 225.

[0031] At 430, the control module 120 provides the configuration information in response to the request. That is, the control module 120 (i.e., the managing controller 230) communicates the obtained configuration information to the requesting device via the transceiver 235. As outlined above, the configuration information includes at least information that enables the requesting device (e.g., a client instance of the control module 120 executing on the computing device 210) to generate a mapping of pins on the test device for communicating with the test device over a network connection. The mapping then serves to facilitate communication with the test device.

[0032] At 440, control module 120 mediates access to the test devices. That is, for example, control module 120 functions to control how communications are routed to the test devices via managing controller 230 and interface library 220. In various mechanisms, control module 120 simply utilizes the generated mapping to provide communications to a particular DUT. However, in further mechanisms, control module 120 functions to emulate a wire harness. That is, when multiple separate DUTs are connected to interface device 200, or multiple interface devices as described further below, control module 120 may emulate the wire harness by directing communications as if the test devices were wired in the same way as if a physical wire harness existed between the test devices.

[0033] For example, signals generated by one test device (i.e., DUT 205) can be routed to another test device as if the devices were connected via a physical wire harness. However, control module 120 instead functions to receive and relay the communications. This allows control module 120 to emulate any configuration of test devices while also gathering diagnostic / analytic data about how the test devices are functioning. Furthermore, control module 120 can further extend the emulated wire harness between multiple interface devices to allow for more complex configurations.

[0034] In that regard, consider FIG. 5, which illustrates an edge network 500. The edge network 500 includes an edge service 505, which is generally similar to the computing device 210 of FIG. 2, a switch 510, and multiple interface devices 515, 520, and 525. The interface devices are configured in a manner similar to the interface device 200 of FIG. 2. However, as shown in the edge network 500, the organization of the DUTs 530, 535, 540, and 545 differs from the previous example. In particular, the interface devices 515 and 520 are shown as sharing a connection with the DUT 535. This example illustrates how the interface devices 515 and 520 can accommodate different organizations. In particular, the interface device 515 may provide connections to some of the pins of the DUT 535, while the interface device 520 may connect to different pins of the DUT 535. This situation may arise in different configurations, such as with a DUT 535 that includes more pins than can be accommodated by a single interface, such as a logical division of the functionality of the DUT 535 for improved management by the interface devices, separating bandwidth between separate interface devices 520, etc.

[0035] As an example, DUT 535 may be a complex module that includes connections to multiple sensors, e.g., multiple cameras. Furthermore, DUT 535 may further include processing power, management, and other functionality built into the different electronic components contained therein. Thus, pins associated with separate functions, or in any desired combination, may be split between two interface devices 515 and 520. In this arrangement, interface devices 515 and 520 separately contain configuration information about the pins connected to each individual device and, in at least one arrangement, also contain general identification information about DUT 535 (e.g., serial number, version number, etc.). In this arrangement, interface device 515 still services DUT 530 in the same manner as described above. Thus, the ability to split pins between separate interface devices provides additional flexibility in emulating wire harnesses.

[0036] The edge network 500 provides an edge service 505 that manages the interface devices 515, 520, and 525. That is, the edge service 505 may function to aggregate information from the interface devices 515-525 to simplify access to a portion of the test service 550. The test service 550 may be a remote client instance that communicates with the edge service 505 to perform automated testing and / or other functions on the DUTs 530-545 individually or in a specific mechanism (e.g., via an emulated wire harness). Thus, the edge service 505 may be configured to perform various management functions, including implementing the interface library 220. In this manner, the edge network 500 provides implementation of more complex mechanisms for the DUTs and also provides access to a wider variety of devices. Furthermore, while devices within an individual edge network are generally co-located, separate edge networks may be physically separated and located far apart. In various mechanisms, cloud services, described in more detail below, may schedule jobs (i.e., access to a particular DUT for testing) within a single edge network, as opposed to spanning multiple edge networks, when feasible. This may provide for running multiple copies of a test in parallel on separate edge networks. Of course, in a further mechanism, virtual wire harnesses may be implemented to allow testing to occur in configurations spanning multiple edge networks.

[0037] Moving further to additional implementations of edge services, consider FIG. 6, which illustrates an exemplary implementation of a cloud-based mechanism. As illustrated in FIG. 6, edge network 500 functions in parallel with an additional edge network 600. Generally, the overall configurations of edge networks 500 and 600 are similar, except that the number of interface devices and associated DUTs may vary depending on the particular implementation. For example, edge network 600 is shown with an edge service 605 and switch 610 that are similar to edge network 500. However, edge network 600 includes two interface devices 615 and 620 with associated DUTs 625, 635, and 640. In further examples, the number of interface devices per edge network may vary to include more or fewer, and even more or fewer DUTs.

[0038] Additionally, cloud service 645 is shown connected to edge network 500 / 600. Cloud service 645 may provide connectivity to more or fewer edge networks than shown in this example. It should be understood that this example is provided for illustrative purposes and should not be construed as a limitation of the overall architecture. In either case, cloud service 645 also functions to aggregate information about DUTs within the connecting interface devices of network 500 / 600. Cloud service 645 may be a service running within a cloud-based device (e.g., a compute server) that connects to a wide area network, the Internet, or another network to provide communication between remote devices. Thus, cloud service 645 functions to provide access to DUTs over the connecting network and may further provide additional functionality. For example, cloud service 645 may provide reservation for access to DUTs, automation interface for access by remote clients, registration of DUTs and emulated harnesses, statistical / analytics reporting, native interface bridging, etc.

[0039] In a further mechanism, cloud services 645 provide bridging of interfaces from separate networks to each other to emulate a wire harness. Stated another way, cloud services 645 may aggregate information from separate interface devices distributed across separate edge networks (e.g., 500 and 600) and form virtual wire harnesses between selected ones of the available DUTs. Cloud services 645 provide access for test entities 650, developers, and / or other network entities, which may include automated testing. Generally, cloud services 645 provide an additional layer of functionality above the interface devices and edge services, as described above.

[0040] As an example, cloud service 645 may provide access for test entity 650, which may be a test device running test software supporting hardware-in-the-loop (HILS), software-in-the-loop (SILS), simulated electronic control units (ECUs) connected via a virtual wire harness, etc. Thus, cloud service 645 may provide access to DUTs 530-545 and 625-635 and / or virtual / emulated wire harnesses that include DUTs 530-545 and 625-635. Thus, in one or more approaches, test entity 650 uses cloud service 645 to create more complex virtual wire harnesses that may include emulated entities (e.g., ECUs) and also provide access to various software routines. In this manner, cloud service 645 provides an interface bridging connection that allows complex test bench configurations and multiple interconnected ECUs to be dynamically provisioned without a physical vehicle wire harness. Thus, rather than implementing a single large test bench with many ECUs connected via physical wiring, each separate ECU can be installed as a DUT in a server rack associated with an interface device and dynamically connected to other ECUs via emulated wire harnesses, thereby providing rapid testing across many different wire harnesses or vehicle variants.

[0041] Additionally, cloud service 645 authorizes and manages reservations for sets of DUTs (e.g., ECUs). Generally, cloud service 645 queues job (e.g., test) requests so that utilization of separate DUTs in different edge networks managed by cloud service 645 is maximized. Once a reservation is granted, cloud service 645 manages the requester's access to one or more edge services so that the requester can connect to the interfaces and route traffic to and from the interfaces. Cloud service 645 may implement this service in various forms. For example, in a first approach, cloud service 645 arranges for the associated edge service to bridge all traffic between the requester and the DUTs (e.g., ECUs) via GRPC or other remote session protocol. This then allows the edge service to have complete control over the connection to prevent malicious actors from accessing the ECUs without a reservation. In another approach, the cloud service 645 manages the edge services to provide routing services (e.g., as IP addresses and ports), and then the requester can connect directly to the ECU using the IP address and port information.

[0042] Additional aspects of using an interfacing device within the context of a cloud service are described in connection with Figure 7. Figure 7 illustrates a flowchart of a method 700 associated with emulating a wire harness. Method 700 is described in terms of interfacing system 100 of Figure 1, with further reference to cloud service 645 of Figure 6. While method 700 is described in combination with the elements shown, it should be understood that method 700 is not limited to implementation within interfacing system 100, but is an example of a system in which method 700 may be implemented.

[0043] At 710, control module 120 monitors for requests from devices. The devices may be test entities 650, test services 550, or another computing entity (e.g., a test server) attempting to access one or more DUTs. In particular, in at least one mechanism, the requests relate to emulating a wire harness. As described herein, emulating a wire harness, or otherwise stated, providing a virtual wire harness, involves mapping available DUTs connected via interface devices to a network and routing communications therebetween according to the virtual associations defined by the emulated wire harness.

[0044] The request may therefore indicate the configuration of the wire harness and the different DUTs connected. Accordingly, control module 120, which may be running as a client instance as part of cloud service 645, monitors the request over the communications link. Upon receipt, control module 120 proceeds to perform additional functions to support emulating the wire harness. If not, control module 120 proceeds to monitor at 710.

[0045] At 720, control module 120 queries the interface devices. In at least one approach, control module 120 provides a query to each separate interface device to obtain configuration information regarding multiple test devices (i.e., DUTs) virtually connected via wire harnesses. In a further mechanism, control module 120 may instead query an edge service (e.g., 505, 605), which may store aggregated information from the interface devices regarding available DUTs. In either case, control module 120 queries each entity and aggregates the configuration information accordingly. As previously mentioned, the configuration information includes information about each DUT (e.g., part number, serial number, etc.) and further includes information about the ports of the bridge to which the DUT's pins are connected, providing for facilitating communication with the DUT.

[0046] At 730, control module 120 generates a harness mapping that identifies connections through each interface device. In particular, control module 120 uses configuration information obtained from the interface devices to define correlations between DUTs through port-to-pin correlations. That is, in one mechanism, control module 120 generates a table, such as a routing table, that indicates which pins should provide signals to other specific pins of different DUTs, such that they would be connected by physical wires if the harness were physically connected. However, because the harness is emulated and virtual, the connections are represented through the harness mapping, which may take the form of a routing table. In this manner, control module 120 can emulate any feature of a device under test simply by providing a specific routing configuration between the pins of the device.

[0047] At 740, control module 120 emulates the wire harness. As mentioned above, the emulation can occur in a cloud service 645 or an edge service (e.g., 505 or 605). Generally, the service providing the emulation simply enables a different range of interactions with different interface devices. In particular, a cloud service 645 enables access across multiple edge networks, while an edge service is limited to interface devices connected within a particular network. In either case, control module 120 may have separate instances running within different services to provide the emulation functionality. Thus, control module 120 uses harness mapping to broker communications between separate DUTs included within the virtual wire harness. In one or more approaches, brokering communications includes control module 120 routing signals between the DUTs according to the harness mapping. Thus, control module 120 identifies the source of the communication (i.e., a particular signal from a particular DUT) and routes the signal to one or more other DUTs according to the harness mapping. In this manner, the interface system 100 can emulate a wire harness to provide an adaptable test bench environment that overcomes the limitations of physical mechanisms.

[0048] Referring to FIG. 8 , an example of a rack system 800 is shown as it may be installed within a server. In particular, the rack system 800 includes three main elements, including a compute rack 805, an interface rack 810, and an interface rack 815. The compute rack 805 includes a network switch that connects to a network to which the other racks 810 are also connected. The compute rack 805 also includes multiple compute servers and a device manager edge. The compute servers may run various instances of the interface system 100 and / or different test services (e.g., test service 215, test service 550, test entity 650). Therefore, automated test programs and other software that may interact with the interfaces may run in the compute rack 805. The interface racks 810 and 815 have a similar configuration, including a network switch that connects to the network and communicates with the compute rack 805. To the network switch, the interface rack 810 connects multiple interface devices, labeled with IDs 820a-f and 825a-f, to associated ECUs, which are devices under test. Thus, rack system 800 provides for implementing complex virtual wire harnesses via edge and cloud services running on compute rack 805. In this manner, the adaptable interfaces (e.g., 820a-f, 825a-f) improve the testing process by avoiding the complexities associated with physical harnesses.

[0049] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are intended merely as examples. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to variously employ the aspects of the present specification in substantially any suitable detailed configuration. Furthermore, the terms and phrases used herein are not intended to be limiting, but rather to provide an understandable description of possible implementations. While various embodiments are shown in FIGS. 1-8, the embodiments are not limited to the illustrated structures or applications.

[0050] 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. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, comprising one or more executable instructions that implement the specified logical function(s). It should also be noted that in some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved.

[0051] The above-described systems, components, and / or processes may be implemented in hardware or a combination of hardware and software, and may be implemented in a centralized fashion within one processing system, or in a distributed fashion with various elements spread across several interconnected processing systems. The systems, components, and / or processes may also be embodied in a computer-readable storage, such as a computer program product or other data program storage device, readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the methods and processes described herein. These elements may also be embodied in an application product having features that enable implementation of the methods described herein and that, when loaded into a processing system, are capable of executing the methods.

[0052] Furthermore, the mechanisms described herein may take the form of a computer program product in which computer-readable program code is embodied, e.g., stored, in one or more computer-readable media. The phrase "computer-readable storage medium" means a non-transitory storage medium. A computer-readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. A non-exhaustive list of computer-readable storage media may include the following: a portable computer diskette, a hard disk drive (HDD), a solid-state drive (SSD), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), an optical storage device, a magnetic storage device, or a combination thereof. In the context of this specification, a computer-readable storage medium is, for example, a tangible medium that stores a program for use by or in connection with an instruction execution system or device.

[0053] Computer program code for carrying out operations for aspects of the present facility may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, or the like, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through a network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider).

[0054] The terms "a" and "an," as used herein, are defined as one or more than one. The term "plurality," as used herein, is defined as two or more than two. The term "another," as used herein, is defined as at least a second or more. The terms "including" and / or "having," as used herein, are defined as comprising (i.e., open language). The phrase "and at least one of," as used herein, refers to and encompasses any and all possible combinations of one or more of the associated listed items. As an example, the phrase "at least one of A, B, and C" includes A only, B only, C only, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0055] Aspects of the present specification may be embodied in other forms without departing from the spirit or essential attributes thereof, and reference should accordingly be made to the following claims, rather than the foregoing specification, as indicating the scope herein.

Claims

1. 1. An interface system comprising: one or more processors; a memory communicatively coupled to the one or more processors and storing a control module including instructions; wherein the instructions, when executed by the one or more processors, cause the one or more processors to: receiving, within an interface device, an initialization request to access a test device, the test device being connected to a bridge at the interface device via a connector pin; obtaining configuration information for the test device from a memory in the interface device, the configuration information including at least a mapping of the connector pins to the bridge; providing the configuration information to facilitate intermediation of communications with the test device; An interface system that allows you to do the following.

2. 2. The interface system of claim 1, wherein the control module includes instructions for providing the configuration information, the instructions including instructions for generating a mapping of pins of the test device for communicating with the test device via the bridge and the connector pins in a network connection.

3. 2. The interface system of claim 1, wherein the control module includes instructions for emulating a wire harness between multiple test devices including the test device, the instructions including instructions for mapping connections using separate configuration information for the multiple test devices queried from the memory of the interface device.

4. 4. The interface system of claim 3, wherein the control module includes instructions to emulate the wire harness between a plurality of interface devices including the interface device, with the plurality of test devices distributed among the plurality of interface devices.

5. The control module querying the plurality of interface devices to obtain configuration information regarding the plurality of test devices virtually connected via the wire harness; generating a harness mapping that identifies connections through respective interface devices for the plurality of test devices to mediate communications among the plurality of test devices; The interface system of claim 4 , further comprising instructions for emulating the wire harness, the instructions comprising instructions for managing the wire harness using an edge service by

6. the control module includes instructions for emulating the wire harness, including instructions for emulating the wire harness between a plurality of edge services, each of which separately communicates with a plurality of interface devices, using a cloud service; The interface system of claim 4 , wherein the control module includes instructions for emulating the wire harness using the cloud service, the instructions including instructions for providing remote access to the interface device via the cloud service.

7. 2. The interface system of claim 1, wherein the control module includes instructions for providing the configuration information to facilitate mediation of communications with the test device, including instructions for mediating access to the test device from the interface device, which is a first device, and an additional interface device, which is a second device, both of which connect to the test device.

8. the first device and the second device providing access to different components of the test device; The interface system of claim 7 , wherein the bridge connects the interface device to an external network.

9. A non-transitory computer-readable medium containing instructions that, when executed by one or more processors, cause the one or more processors to: receiving, within an interface device, an initialization request to access a test device, the test device being connected to a bridge at the interface device via a connector pin; obtaining configuration information for the test device from a memory in the interface device, the configuration information including at least a mapping of the connector pins to the bridge; providing the configuration information to facilitate intermediation of communications with the test device; A non-transitory computer-readable medium for causing

10. 10. The non-transitory computer-readable medium of claim 9, wherein the instructions for providing the configuration information include instructions for generating a mapping of pins of the test device for communicating with the test device through the bridge and the connector pins in a network connection.

11. 10. The non-transitory computer-readable medium of claim 9, wherein the instructions for emulating a wire harness between a plurality of test devices including the test device include instructions for mapping connections using separate configuration information for the plurality of test devices queried from the memory of the interface device.

12. 12. The non-transitory computer-readable medium of claim 11, wherein the instructions for emulating the wire harness include instructions for emulating the wire harness between a plurality of interface devices including the interface device, with the plurality of test devices distributed among the plurality of interface devices.

13. The instructions for emulating the wire harness include: querying the plurality of interface devices to obtain configuration information regarding the plurality of test devices virtually connected via the wire harness; generating a harness mapping that identifies connections through respective interface devices for the plurality of test devices to mediate communications among the plurality of test devices; 13. The non-transitory computer-readable medium of claim 12, comprising instructions for managing the wire harness using an edge service by

14. receiving, within an interface device, an initialization request to access a test device, the test device being connected to a bridge at the interface device via a connector pin; obtaining configuration information for the test device from a memory in the interface device, the configuration information including at least a mapping of the connector pins to the bridge; providing the configuration information to facilitate intermediation of communications with the test device; A method comprising:

15. 15. The method of claim 14, wherein providing the configuration information includes generating a mapping of pins of the test device for communicating with the test device through the bridge and the connector pins in a network connection.

16. 15. The method of claim 14, further comprising emulating a wire harness between a plurality of test devices, including the test device, by mapping connections using separate configuration information for each of the plurality of test devices queried from the memory of the interface device.

17. 17. The method of claim 16, wherein emulating the wire harness includes emulating the wire harness between a plurality of interface devices including the interface device, with the plurality of test devices distributed among the plurality of interface devices.

18. emulating the wire harness querying the plurality of interface devices to obtain configuration information regarding the plurality of test devices virtually connected via the wire harness; generating a harness mapping that identifies connections through respective interface devices for the plurality of test devices to mediate communications among the plurality of test devices; 20. The method of claim 17, comprising managing the wire harness using an edge service by

19. emulating the wire harness includes emulating the wire harness between a plurality of edge services, each of which separately communicates with a plurality of interface devices, using a cloud service; 20. The method of claim 17, wherein using the cloud service to emulate the wire harness includes providing remote access to the interfacing device via the cloud service.

20. providing the configuration information to facilitate mediating communication with the test device includes mediating access to the test device from the interface device, which is a first device, and an additional interface device, which is a second device, both of which connect to the test device; the first device and the second device providing access to different components of the test device; The method of claim 14 , wherein the bridge connects the interfacing device with an external network.

Images