Adaptable hardware interface for testing devices

Abstract

The systems, methods, and further embodiments described here relate to improving the testing of electronic devices using adaptable interfaces. In one embodiment, a method comprises receiving an initialization request within an interface device to access a test device, wherein the test device is connected to a bridge in the interface device via connecting pins. The method includes querying configuration information about the device from a memory within the interface device, which includes at least a mapping of the connecting pins to the bridge. The method includes providing the configuration information to facilitate communication with the device.

Description

TECHNICAL AREA

[0001] The subject matter described here generally relates to the testing of electronic devices and, in particular, to an adaptable interface that allows easy access to the devices under test in a configurable manner. STATE OF THE ART

[0002] Developers use test benches to create a controlled environment for developing software for new devices and to verify that the new devices function as expected. Generally, test benches are built individually for each device. In the context of electronic control units (ECUs) in vehicles, for example, a test bench might include a custom-designed wiring harness that connects various devices while also providing additional connections for testing purposes. However, the unique nature of these test benches requires institutional expertise to use effectively, limiting the possibility of many developers sharing them and making access more difficult overall.Furthermore, as the complexity of the device or the arrangement of the devices under test increases, and / or as testing requirements rise, the wiring harnesses become increasingly complex and difficult to construct and maintain. This increased complexity also leads to higher costs for a non-reusable test setup, resulting in further waste. SUMMARY

[0003] Example systems and methods relate to the testing of electronic devices using an adaptable interface. As mentioned earlier, test benches can be complex to implement due to various considerations, including the complexity of the device(s) under test. This leads to increased costs and waste, as these test benches are complicated to implement and generally not reusable. Therefore, at least one approach discloses a system according to the invention that provides an adaptable interface and associated logic for improving the testing of electronic devices. For example, at least one aspect includes an interface device with a controller, a memory, a bridge, and a connection device to support communication with a device under test (i.e., an electronic device).The electronic device can take many different forms, including a module with multiple die packages, a single die package, and so on. As described here, the electronic device is generally an electronic control unit such as might be used in a vehicle. Although the present disclosure focuses on the context of a vehicle, the disclosed devices, systems, and methods are also applicable in other contexts.

[0004] In any case, it's important to remember that an electronic device, such as an ECU or multiple ECUs, is generally connected via a complex wiring harness when installed in a vehicle. This harness may include a connection for each individual ECU with intermediate wiring. Furthermore, during testing, the harness may also include diagnostic connection devices to provide diagnostic signals. However, as mentioned earlier, developing a unique wiring harness for every different configuration of electronic devices that might need to be tested is complex. The interface device solves this problem by using a bridge to connect to multiple electronic devices under test, such as several different ECUs.The bridge is connected to a corresponding electronic device via connecting pins, which can be separate pins of a device or a combined connection device. The connecting pins link the bridge to an explicit terminal belonging to the electronic device under test (e.g., an ECU) or directly to the pins of a chip package or other electronic device (e.g., a sensor).

[0005] Consequently, the connection pins can be specific to each electronic device, but this replaces a more complex wiring harness that cannot be adapted to different layouts. Since the connection pins from the bridge to the electronic device are unique in each case, the interface also includes a memory, which may be an EEPROM or similar non-volatile memory, that stores configuration information about the electronic device and any other devices under test connected to the bridge via connection pins. The content of the configuration information can vary depending on the implementation, but generally includes descriptive data to identify the electronic device (e.g., serial number or other identifier, version number, etc.) and a mapping of the connection pins.The mapping identifies the correlation between the pins of the electronic device and the terminals of the bridge to which the pins are connected and enabled for communication. Accordingly, a controller facilitates access to the electronic device by transmitting the configuration information, allowing a test server or other test management system to access the electronic device.

[0006] In various configurations, the interface device communicates with an edge service and / or a cloud service designed to simplify access to the device(s) under test. The edge service can aggregate configuration information from multiple different interface devices connected to various electronic devices. For example, the edge service can connect to the interface device via an Ethernet switch or other communication interface network and retrieve configuration information for a range of electronic devices connected to different interface devices. The edge service then creates a mapping of the group of electronic devices and their associated connections provided via the respective bridges.A test system can then use the edge service to create a virtual wiring harness via mapping, emulating connections between the various electronic devices. This means the edge service can connect the different electronic devices via interface devices in a similar way to a physical wiring harness, but without the complexity and overhead of implementing the harness. Furthermore, a cloud service can aggregate mappings from multiple edge services. The cloud service can then enable access for remote clients and provide additional functionality, such as the provision of more complex virtual wiring harnesses between separate edge services, reservations, data analysis, and so on, thereby improving access to the device(s).In this way, the presented approach can improve the testing of electronic devices by avoiding complex, expensive and potentially wasteful physical wiring harnesses for testing.

[0007] In one embodiment, an interface system is disclosed. The interface system comprises one or more processors and a memory that is communicatively connected to the one or more processors. The memory stores a control module that includes instructions which, when executed by the one or more processors, cause the one or more processors to receive an initialization request within an interface device to access a test device, wherein the test device is connected to a bridge in the interface device via connecting pins. The control module includes instructions for querying configuration information about the device from a memory within the interface device, which includes at least one mapping of the connecting pins to the bridge.The control module includes instructions for providing configuration information to facilitate communication with the device.

[0008] In one embodiment, a non-transitory, computer-readable medium is disclosed, comprising 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 an initialization request in an interface device to access a test device, the test device being connected to a bridge in the interface device via connecting pins. The instructions include instructions for querying configuration information about the device from a memory within the interface device, which includes at least a mapping of the connecting pins to the bridge. The instructions include instructions for providing the configuration information to facilitate communication with the device.

[0009] In one embodiment, a method is disclosed. In one embodiment, the method comprises receiving an initialization request within an interface device to access a test device, wherein the test device is connected to a bridge in the interface device via connecting pins. The method includes querying configuration information about the device from a memory within the interface device, which includes at least a mapping of the connecting pins to the bridge. The method includes providing the configuration information to facilitate communication with the device. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which form part of the description, illustrate various systems, methods, and other embodiments of the disclosure. The illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one embodiment of the boundaries. In some embodiments, an element may be implemented as multiple elements, or multiple elements 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. Furthermore, elements may not be drawn to scale. Fig. Figure 1 illustrates an embodiment of an interface system connected to an adaptable platform for testing electronic devices. Fig. Figure 2A illustrates an exemplary embodiment of an interface device and connected devices. Fig. 2B illustrates an embodiment of the interface device of Fig. 2A, illustrating additional details. Fig. Figure 3 illustrates a flowchart of the communication between an interface device and a testing service. Fig. Figure 4 is a flowchart representing a procedure associated with the use of an interface device to mediate communications with a device under test. Fig. Figure 5 illustrates a configuration of an edge service that includes multiple interface devices. Fig. Figure 6 illustrates a configuration of a cloud-based service that uses interface devices to emulate physical cable harnesses. Fig. Figure 7 is a flowchart illustrating a procedure associated with emulating a wiring harness. Fig. Figure 8 is a diagram illustrating an arrangement of a rack system that houses multiple networks of interface devices. DETAILED DESCRIPTION

[0011] Systems, methods, and other embodiments related to testing electronic devices using an adaptable interface are disclosed. As mentioned earlier, test benches can be complex to implement due to various considerations, including the complexity of the device(s) under test. This leads to increased costs and waste, as these test benches are complicated to implement, unique to each specific case, and therefore cannot be reused. For example, in a vehicle, a wiring harness may be connected to a dozen or more electronic control units. Each of these electronic control units (ECUs) is designed and tested to implement specific functions in the vehicle in the manner desired by the developers.Therefore, every different configuration of systems within a vehicle during development, and every separate iteration of different control units that might be selected, requires a new wiring harness that must be manufactured manually. Consequently, the ability to iterate designs when developing a new platform can be costly, potentially limiting development.

[0012] Therefore, at least one approach discloses an inventive system that provides an adaptable interface and associated logic for improving the testing of electronic devices. In at least one aspect, an interface device includes, for example, a controller, memory, bridge, and interconnection device to support communication with a device under test (i.e., an electronic device, also referred to herein as the test device). The electronic device can take many different forms, including a multi-chip package module, a single-chip package, a system-on-a-chip (SoC), and so on. As described herein, the electronic device is generally an electronic control unit (ECU), such as might be used in a vehicle.Although the present disclosure focuses on the context of a vehicle, the disclosed devices, systems and methods are also applicable to other contexts, and the context discussed should not be understood as a limitation.

[0013] In any case, it's important to remember that electronic devices, such as one or more ECUs, are generally connected via a complex wiring harness when installed in a vehicle. This harness may include a connection for each individual ECU with intermediate wiring. Furthermore, during testing, the harness may also include diagnostic connection devices to provide diagnostic signals. However, as mentioned earlier, developing a unique wiring harness for every different configuration of electronic devices that might need to be tested is complex. The interface device solves this problem by using a bridge to connect to multiple electronic devices under test, such as several different ECUs.The bridge is connected to a corresponding electronic device via connecting pins. These connecting pins link the bridge to a specific terminal connected to the electronic device under test (e.g., an ECU), or directly to the pins of a chip package or other electronic device (e.g., a sensor).

[0014] Consequently, the connection pins can be specific to each electronic device, thus replacing a more complex wiring harness that cannot be modified for different configurations. Since the connection pins from the bridge to the electronic device are unique in each case, the interface device also includes a memory component, which may be an EEPROM or similar non-volatile memory, that stores configuration information about the electronic device and any other devices under test connected to the bridge via different connection pins. The content of the configuration information may vary depending on the implementation, but generally includes descriptive data to identify the electronic device (e.g., serial number or other identifier, version number, etc.) and a mapping of the connection pins.The mapping identifies the correlation between the pins of the electronic device and the terminals of the bridge to which the pins are connected and enabled for communication. Accordingly, a controller facilitates access to the electronic device by transmitting the configuration information, allowing a test server or other test management device to access the electronic device via the bridge using the mapping.

[0015] In various other configurations, the interface device communicates with an edge service and / or a cloud service. The edge service can communicate with the interface device via a network connection to aggregate configuration information from multiple different interface devices connected to various electronic devices. For example, the edge service can connect to the interface device via an Ethernet switch or a communication interface and obtain configuration information for a range of electronic devices connected to different interface devices. The edge service then creates a mapping of the group of electronic devices and their associated connections provided via the respective bridges.A test system can then use the edge service to create a virtual wiring harness using mapping, in order to emulate connections between the various electronic devices. That is, the edge service can provide the connection of the various electronic devices via the interface devices in a similar way to how a physical wiring harness would, but without the complexity and effort of implementing the wiring harness.

[0016] Furthermore, a cloud service can aggregate mappings from multiple edge services to provide additional functionality. The cloud service can not only enable access for remote clients but also provide additional features, such as the provision of more complex virtual wiring harnesses between separate edge services, reservations for scheduling tests between different units, data analytics, and so on. In this way, the presented approach is able to improve the testing of electronic devices by avoiding complex, expensive, and potentially wasteful physical wiring harnesses for testing.

[0017] With reference to Fig. Figure 1 illustrates an embodiment of an interface system 100. The interface system 100 is shown to include a processor 110, which may be integrated into the interface system 100 or connected to a separate device, such as a server, a cloud computing system, and so on. Accordingly, the processor 110 may be part of the interface system 100, or the interface system 100 may access the processor 110 via a data bus or other communication path. In one embodiment, the interface system 100 includes a memory 130 in which a control module 120 is stored. The memory 130 is random-access memory (RAM), read-only memory (ROM), a hard disk drive, flash memory, or another suitable memory for storing the module 120.Module 120, for example, consists of computer-readable instructions which, when executed by processor 110, cause processor 110 to perform the various functions disclosed therein. In alternative configurations, module 120 is independent of memory 130 and includes, for example, hardware elements (e.g., arrays of logic gates). Thus, module 120 is alternatively an ASIC, a hardware-based controller, an array of logic gates, or another hardware-based solution.

[0018] The interface system 100, as in Fig. Figure 1 illustrates an abstracted form of Interface System 100, as it can be implemented as part of an interface device, an edge service, and / or a cloud computing system. It should be noted that the functionality discussed with respect to Interface System 100 may be entirely contained within a single device, e.g., the interface device itself, or it may be distributed across several different devices, e.g., interface devices, compute elements acting as edge services, compute elements acting as cloud services, and so on. The functionality discussed with respect to Fig. The special arrangement described in point 1 is therefore not intended as a limitation, but as an example of how the specific functions described here can be implemented in relation to a device.

[0019] With reference to Fig. Figure 2A illustrates an example of an interface device 200 (here also referred to as a hardware interface (HWI)). The interface device 200 is connected, as shown, to a device under test (DUT) 205. The DUT 205 can generally be any electronic device under test, such as an ECU or other electronic module. The interface device 200 is connected to the DUT 205 via connection pins specific to the DUT 205. As illustrated in this example, the connection pins have three primary connections, each of which can include several separate wires. Specifically, the DUT 205 is connected via a control surface (CAN) connection, a 12V / A connection, and a power line. These separate sections of the connection devices are each connected to a CAN port, an IGN port, and a power input, respectively.As can be seen from the present example, the connection devices for each individual test object can be unique and are therefore implemented in at least one arrangement based on the individual devices. An additional aspect is that the interface device 200 in . Fig. Although 2A is shown as a connection to a single device under test 205, the interface device 200 can connect several separate devices under test in various configurations. The number of devices to which the interface device 200 can be connected is generally limited only by the characteristics of the hardware contained within the interface device 200 itself, such as a communication bridge, which may have a specific number of ports to which it can be connected.

[0020] Regardless, in the illustrated example, the interface device 200 is connected to a computing device 210. The computing device 210, in one or more configurations, is a server, a desktop computer, a laptop, or another device capable of executing instructions for testing the DUT 205 and communicating via the interface device 200. The device 210 executes a testing service 215, which includes instructions for testing the DUT 205. The service 215 may, for example, include instructions for automated testing and / or a manual interface to the DUT for manual testing. The testing can take different forms depending on its intended use, but may include diagnostic testing, the development of software for use on the DUT 205, troubleshooting, and so on.

[0021] In any case, the service uses interface libraries 220 to establish an interface with the interface device 200 and the device under test 205. That is, the interface libraries 220 can form an application programming interface (API) or another software library that provides functions to facilitate communication between the computing device 210 and the interface device 200 via an Ethernet connection or another electronic communication link. Further details of the interface device 200 are described in Fig. 2B shows the additional components of an example of the interface device 200. Fig. Figure 2A shows that, as illustrated, the interface device 200 comprises a memory 225, a management controller 230, a transceiver 235, and a bridge 240.

[0022] The transceiver 235 establishes communication with the computer device 210 via an Ethernet connection or another communication link and can itself forward the communication within the interface device 200. For example, depending on the requirements provided by the computer device 210 via the interface devices 220, the transceiver 235 can control the communication to the management controller 230 or directly to the bridge 240. The management controller 230 can be an ASIC, logic, or other programmable processing device that handles initialization requests from the computer device 210 or another external device. For example, the management controller 230 can receive an initialization request for information about one or more test objects connected to the interface device 200.In general, the interface device 200 stores configuration information for each device under test connected to it. The interface device 200 can store this configuration information in memory 225. Memory 225 could be, for example, an EEPROM or other non-volatile memory.

[0023] The configuration information stored in memory 225 includes information about the device under test (DUT) 205 and the interconnects that connect DUT 205 to bridge 240. The information about DUT 205 can include a device identifier, a version number, and other attributes (e.g., device specifications such as memory, processing capabilities, etc.). The information about the interconnects includes a mapping or listing of how the pins of DUT 205 are connected to bridge 240. Thus, the pin information correlates the pins with the ports of bridge 240, allowing the requesting device (i.e., the computing device 210) to create a mapping for subsequent power supply, control, and other communication with DUT 205.Accordingly, the test service 215 uses the interface device 220 to create a mapping that forwards the signals generated by the test service 215 during the execution of a test program to the corresponding pins of the device under test (DUT) 205. In general, the mapping defines ports connected to the bridge 240 to transmit signals to specific pins of the DUT 205. In this way, the interface device 200 makes the DUT 205 accessible for interaction with external devices.

[0024] In Fig. Figure 3 represents an example 300 of the communication between the test service 215, the interface library 220, and the interface device 200. As additional context, in at least one arrangement, the test service 215 is an automated test program that delivers a defined set of inputs to the device under test 205 and records the responses to characterize the performance of the device under test 205 (e.g., whether the device under test 205 is working as expected). In other arrangements, the test service 215 can be a development environment for generating software code and loading the software code into the device under test 205 for execution. In still other arrangements, the service 215 is an interface for manual testing that allows a user to select inputs to be delivered directly to the device under test 205. In yet other arrangements, the test service 215 is a client for external requests from remote applications.For example, the test service 215 can form an interface to an edge service, a cloud-based service or another entity to enable access to the test object 205 or other connected test objects of the interface device 200.

[0025] In any case, the test service 215 initiates communication with the interface device 200 at 305. To enable communication in a suitable form, the interface libraries 220, which can be implemented as commands as part of the test service 215, process the request into a query to the interface device, as shown in 310. In response to the query, the interface device 200 retrieves the configuration information from memory 225 via the management controller 230 and transmits the configuration information back to the interface libraries, which is depicted as a multi-stage process in 315. Although it is shown that the configuration information is retrieved in several steps, the interface device 200 can provide the contents of the configuration information in a single communication or in multiple communications, depending on, for example, the configuration.Buffer sizes and / or other hardware limitations.

[0026] The interface libraries 220 then generate the mapping of the pins of the device under test (DUT) 205, which is connected to the interface device 200, so that the interface library 220 can translate requests from the test service 215 and forward the requests to the corresponding ports of the bridge 240. Once the interface libraries 220 have initialized the mapping, which can be implemented as a list, table, or other data structure that correlates the ports with the pins, the test service 215 is able to query the interface libraries 220 for information about the DUT 205, as shown in Figure 320, such as an identifier, a version number, connected pins / interfaces available to the DUT 205, and so on. It should be noted that although a single DUT 205 is described, the information returned by the interface device 200 may encompass multiple DUTs in further configurations.The interface libraries 220 can then provide information about several separate devices under test. Fig. Figure 3 further illustrates how the service 215 interacts with the device under test 205 via the interface device 200. The illustrated communication processes generally include switching on the device under test 205, communicating with the device under test 205, and obtaining diagnostic information, such as status reports, from the device under test 205 via the connected pins.

[0027] Further aspects of using an interface device to facilitate communication during testing are discussed in connection with Fig. 4 discussed. Fig. Figure 4 illustrates a flowchart of a process 400 that is connected to a device under test (DUT) via an adaptable interface. The process 400 is viewed from the perspective of the interface system 100. Fig. 1 with further reference to the interface device 200 of Fig. 2A-B is discussed. While discussing Procedure 400 in combination with the aforementioned elements, it should be understood that Procedure 400 is not limited to being implemented within Interface System 100, but is instead an example of a system that can implement Procedure 400.

[0028] In the 410 configuration, the control module 120 monitors the requirements of a device connected to the interface device 200. For example, the interface device 200 can be directly connected to another device or to a network through which several different devices can communicate. In various configurations, the interface device 200 connects to the network or directly to the other device via an Ethernet cable or another suitable communication link. In each case, the module 120, which can be implemented at least partially as an administrative controller 230, monitors the communication and identifies or otherwise distinguishes between different communications.In one approach, the control module 120 monitors a specific flag in the communication or analyzes the communication in another way to determine whether the communication is an initialization request for accessing a device (i.e., a device under test) connected to the bridge 240. If the communication is an initialization request, the control module 120 proceeds to query configuration information as described in section 420. Otherwise, the module 120 continues monitoring the communication.

[0029] At 420, the control module 120 queries configuration information from a memory within the interface device 200. As previously described, the memory 225 stores configuration information for devices connected to the bridge 240 of the interface device 200. Thus, the memory 225 can store a different selection of configuration information depending on how many devices are connected to the interface device. Depending on the configuration, the control module 120 can query the configuration information for all connected devices or for the device(s) specified in the request. This allows the control module 120 to analyze the request to identify its attributes, which generally include the devices under test for which information is being requested.In alternative arrangements, the control module 120 can of course also simply query information for all test objects for which configuration information is available in memory 225.

[0030] At 430, the controller module 120 provides the configuration information in response to the request. That is, the module 120 (i.e., the management controller 230) transmits the requested configuration information to the requesting device via the send / receiver 235. As described previously, the configuration information includes at least information that allows the requesting device (e.g., a client instance of the control module 120 running on the computer device 210) to create a pin mapping of the device for communication with the test device over the network connection. This mapping then facilitates communication with the test device.

[0031] In configuration 440, the control module 120 provides access to the device(s). This means that the module 120, via the management controller 230 and the interface devices 220, controls how communication with the device(s) under test is routed. In some configurations, the control module 120 simply uses the generated mapping to establish communication with a specific device under test. However, in other configurations, the module 120 functions by emulating a wiring harness. That is, if several separate devices under test are connected to the interface device 200 or to multiple interface devices, as described below, the module 120 can emulate a wiring harness by controlling the communication as if the interface devices were wired in the same way as if a physical wiring harness existed between the devices under test.

[0032] For example, signals generated by one test fixture (i.e., DUT 205) can be routed to another test fixture as if the fixtures were connected via a physical wiring harness. However, the control module 120 receives and forwards the communication. This allows the module 120 to emulate any configuration of fixtures while simultaneously collecting diagnostic / analytical data about the fixtures' operation. Furthermore, the control module 120 can extend an emulated wiring harness to multiple interface fixtures to enable more complex configurations.

[0033] In this context, it should be noted Fig. Reference is made to Figure 5, which illustrates a boundary network 500. The boundary network 500 has a boundary service 505, which is generally assigned to the computing device 210. Fig. 2, as well as a Switch 510 and several interface devices 515, 520, and 525. The interface devices are configured similarly to the Interface Device 200 in Fig. 2. However, as shown in the boundary network 500, the arrangement of the devices under test 530, 535, 540, and 545 differs from the previous example. In particular, the interface devices 515 and 520 are shown as common connections with the device under test 535. This example illustrates how the interface devices 515 and 520 can be adapted to different arrangements. Specifically, the interface device 515 can provide a connection to a section of the pins of the device under test 535, while the interface device 520 can provide a connection to other pins of the device under test 535. This can occur in various configurations, e.g.because the device under test 535 has more pins than can be accommodated by a single interface, in order to divide the bandwidth between the separate interface devices 520, as a logical division of the functions of the device under test 535 for better management by the interface devices, etc.

[0034] For example, the device under test (DUT) 535 can be a complex module that includes connections to multiple sensors, such as several cameras. Furthermore, the DUT 535 can also include processing, management, and other functions that are integrated into several different electronic components within it. The pins assigned to the individual functions can be distributed between the two interface devices 515 and 520, even in any combination. In this arrangement, the interface devices 515 and 520 separately contain configuration information for the pins connected to each individual device and, in at least one arrangement, also general identification information (e.g., serial number, version number, etc.) for the DUT 535. In this arrangement, the interface device 515 continues to provide the DUT 530 with the same service as previously described.Accordingly, the ability to divide the pins between separate interface devices offers additional flexibility when emulating a wiring harness.

[0035] The 500 edge network specifies that the 505 edge service manages the 515, 520, and 525 interface devices. This means that the 505 edge service can aggregate information from the 515-525 interface devices to simplify access for a 550 test service. The 550 edge service can be a remote client instance that communicates with the 505 edge service to perform automated tests and / or other functions on the devices under test (DUTs) 530-545, either individually or in a specific configuration (e.g., via an emulated wiring harness). The 505 edge service can be configured to perform various management functions, including the implementation of the 220 interface libraries. In this way, the 500 edge network enables the implementation of more complex configurations of DUTs and access to a wider variety of devices.Furthermore, the devices within a single edge network are typically located in a common location, whereas separate edge networks can be physically far apart and located in remote locations. In various configurations, a cloud service, described in more detail below, can schedule jobs (i.e., accessing specific devices under test to perform tests) within a single edge network, rather than spanning multiple edge networks where possible. This allows multiple copies of a test to run in parallel on separate edge networks. Of course, in other configurations, virtual cable harnesses can be implemented, and tests can be performed in configurations spanning multiple edge networks.

[0036] Further implementations of edge services are in Fig. 6 shown. Fig. Figure 6 illustrates a sample implementation of a cloud-based arrangement. As shown in Fig. As shown in Figure 6, the edge network 500 operates in parallel with another edge network 600. In general, the overall configuration of edge networks 500 and 600 is similar, except that the number of interface devices and connected devices under test (DUTs) may vary depending on the specific implementation. For example, edge network 600 is shown with an edge service 605 and a switch 610, which is similar to edge network 500. However, edge network 600 includes two interface devices, 615 and 620, with associated DUTs 625, 630, and 640. In other examples, the number of interface devices per edge network may vary, and the number of DUTs may vary.

[0037] Additionally, a cloud service 645 is shown, which is connected to the edge networks 500 / 600. The cloud service 645 can be connected to more or fewer edge networks than shown in this example. It should be noted that this example is shown for illustrative purposes and should not be understood as limiting the overall structure. In any case, the cloud service 645 also serves to collect information about the devices under test in the connected interface devices of the networks 500 / 600. The cloud service 645 can be a service running on a cloud-based device (e.g., a computing server) that is connected to a wide area network, the internet, or another network to enable communication between remote devices.The Cloud Service 645 enables access to the devices under test via the connected networks and can also provide additional functions. For example, the Cloud Service 645 can provide reservations for access to the devices under test, automatic registration of interfaces, devices under test, and emulated wiring harnesses for access by remote clients, statistical / analytical reports, bridges for native interfaces, etc.

[0038] In further configurations, the Cloud Service 645 ensures that the interfaces from the separate networks are interconnected to emulate a wiring harness. In other words, the Cloud Service 645 aggregates the information from the individual interface devices distributed across the various edge networks (e.g., 500 and 600) and can form a virtual wiring harness between selected devices under test. The Cloud Service 645 provides access for a Test Unit 650, which can include automated tests, developers, and / or other networked units. Generally, the Cloud Service 645 provides additional functional layers above the interface devices and edge services, as previously described.

[0039] For example, the Cloud Service 645 can provide access for the Test Unit 650, which may be a device running test software that supports hardware-in-loop (HILS), software-in-loop (SILS), simulated electronic control units (ECUs) connected via a virtual wiring harness, and so on. Thus, the Cloud Service 645 can provide access to the devices under test (DUTs) 530-545 and 625-635 and / or virtual / emulated wiring harnesses that include the DUTs 530-545 and 625-635. In this way, the Test Unit 650 uses the Cloud Service 645 in one or more approaches to create more complex virtual wiring harnesses that can include emulated entities (e.g., ECUs) and also provide access for various software routines.In this way, the Cloud Service 645 provides an interface bridge that enables the dynamic deployment of complex test bench configurations and multiple interconnected ECUs without physical wiring harnesses. Instead of implementing a single large test bench with many ECUs connected via physical wiring, each individual ECU can be installed as a device under test in a server rack connected to an interface device and can be dynamically connected to other ECUs via an emulated wiring harness, thus enabling rapid testing across many different wiring harnesses or vehicle variants.

[0040] Furthermore, Cloud Service 645 accepts and manages reservations for a number of devices under test (e.g., ECUs). Generally, Cloud Service 645 queues job requests (e.g., testing) to maximize the utilization of each device under test across the various edge networks managed by Cloud Service 645. Once a reservation is granted, Cloud Service 645 manages a requester's access to one or more edge services, enabling the requester to connect to interfaces and route traffic to and from them. Cloud Service 645 can implement this service in various ways. For example, in one approach, Cloud Service 645 ensures that an associated edge service bridges all traffic between the requesting party and the device under test (e.g., ECU) over a GRPC or other remote session protocol.The edge service is then able to fully control the connection to prevent malicious actors from accessing the ECU without a reservation. In another approach, the Cloud Service 645 manages the edge service to provide routing services (e.g., as IP address and port), allowing the requesting party to connect directly to the ECU using that IP address and port information.

[0041] Further aspects of using an interface device in a context of cloud services are discussed in connection with Fig. 7 discussed. Fig. Figure 7 illustrates a flowchart of a procedure 400 associated with the emulation of a wiring harness. The procedure 700 is presented from the perspective of interface system 100. Fig. 1 with further reference to the cloud service 645 of Fig. 6. While discussing Procedure 700 in combination with the aforementioned elements, it should be noted that Procedure 700 is not limited to being implemented within Interface System 100, but is instead an example of a system that can implement Procedure 700.

[0042] In configuration 710, the control module 120 monitors requests from a device. The device may be the test station 650, the test service 550, or another computing unit (e.g., a test server) attempting to access one or more devices under test. Specifically, in at least one configuration, the request relates to the emulation of a wiring harness. As described herein, emulating a wiring harness, or in other words, providing a virtual wiring harness, involves mapping available devices under test that are connected to a network via interface devices and routing the communication between them according to virtual mappings defined by the emulated wiring harness.

[0043] Accordingly, the request can specify a wiring harness configuration and various test objects to be connected. As such, the control module 120, which can run as a client instance as part of the cloud service 645, monitors the requests via a communication link. Upon receipt, the control module 120 performs further functions to emulate the wiring harness. Otherwise, the module 120 continues monitoring at 710.

[0044] At 720, the control module 120 queries the interface device(s). In at least one approach, the control module 120 provides queries to each individual interface device to retrieve configuration information for the multiple devices under test (i.e., devices under test) that are to be virtually connected via the wiring harness. In another arrangement, the module 120 instead queries edge services (e.g., 505, 605) that can store aggregated information from the interface devices about available devices under test. In each case, the module 120 queries the relevant entities and aggregates the configuration information as a response. As mentioned earlier, the configuration information includes information about the respective device under test (e.g., part number, serial number, etc.) and also information about the terminals of the bridge to which the device under test pins are connected, which facilitates communication with the device under test.

[0045] At 730, the controller module 120 generates a mapping of the wiring harness that identifies the connections via the respective interface devices. Specifically, the controller module 120 uses the configuration information obtained from the interface devices to define correlations between the devices under test (DUTs) via the port-to-pin correlations. That is, the controller module 120 generates a table, for example, a routing table, that specifies which pins should supply signals to other specific pins of different DUTs, just as they would be connected with a physical wire if the wiring harness were physically connected. However, since the wiring harness is emulated and virtual, the connections are represented by the wiring harness mapping, which can take the form of a routing table.In this way, the control module 120 can emulate any arrangement of devices by simply providing a specific routing configuration between the pins of the devices under test.

[0046] At 740, the controller module 120 emulates the wiring harness. As previously described, the emulation can be performed via the Cloud Service 645 or the edge service (e.g., 505 or 605). Generally, the service providing the emulation simply allows a different level of interaction with different interface devices. Specifically, the Cloud Service 645 allows access across multiple edge networks, while the edge service is limited to the interface devices connected within the respective network. In either case, the controller module 120 can have separate instances running within the different services to provide the emulation functionality. The module 120 manages the communication between the individual devices under test, which comprise a virtual wiring harness, by mapping the harness.In one or more approaches, the communication facilitation includes the control module 120, which routes the signals between the DUTs according to the wiring harness mapping. Thus, the control module 120 identifies the source of the communication (i.e., a specific signal from a particular DUT) and routes the signal to one or more other DUTs according to the wiring harness mapping. In this way, the interface system 100 is able to emulate a wiring harness and provide an adaptable test bench environment that overcomes the limitations of the physical setup.

[0047] In Fig. Figure 8 illustrates how a Rack System 800 can be installed in a server. The Rack System 800 has three main components: a Computing Rack 805, an Interface Rack 810, and an Interface Rack 815. The Computing Rack 805 includes a network switch for connecting to a network to which the other Racks 810 are also connected. The Computing Rack 805 also includes several computer servers and a device for managing equipment. Various instances of the Interface System 100 and / or different test services (e.g., Test Service 215, Test Service 550, Test Unit 650) can run on the computer servers. This allows automated test programs and other software that interacts with the interfaces to run on the Computer Rack 805.Interface racks 810 and 815 are similarly configured and include network switches for connecting to the network and communicating with computer rack 805. Using these network switches, interface racks 810 connect multiple interface devices, identified by IDs 820a-f and 825a-f, to associated control devices, which are the devices under test. This allows the 800 rack system to implement complex virtual cable harnesses across edge and cloud services running on computer rack 805. In this way, the adaptable interfaces (e.g., 820a-f, 825a-f) improve the testing process by eliminating the complexities associated with physical cable harnesses.

[0048] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are intended only as examples. Therefore, specific structural and functional details disclosed herein are not to be understood as limiting, but merely as a basis for the claims and as a representative basis to show a person skilled in the art how to incorporate the aspects contained herein into virtually any appropriately detailed structure. Furthermore, the terms and expressions used herein are not to be understood as limiting, but rather are intended to provide an understandable description of possible implementations. Various embodiments are described in the Fig. Figures 1-8 are shown, but the embodiments are not limited to the illustrated structure or application.

[0049] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, procedures, and computer program products according to various examples. In this respect, each block in the flowcharts or block diagrams can represent a module, segment, or section of code containing one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions shown in the blocks may occur in a different order than shown in the figures. For example, two blocks shown consecutively may, in reality, be executed essentially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality involved.

[0050] The systems, components, and / or processes described above can be implemented in hardware or a combination of hardware and software, and can be implemented centrally in a single processing system or in a distributed manner, with different elements distributed across multiple interconnected processing systems. The systems, components, and / or processes can also be embedded in computer-readable memory, such as a computer program product or other data program storage device, which is machine-readable and embodies a program with instructions that can be executed by the machine to perform the procedures and processes described herein.These elements can also be embedded in an application product that has the features that enable the execution of the procedures described herein and that, when loaded into a processing system, is able to execute these procedures.

[0051] Furthermore, the arrangements described here can take the form of a computer program product embodied in one or more computer-readable data carriers on which computer-readable program code is embodied, e.g., stored. The term "computer-readable storage medium" means a non-transient storage medium. A computer-readable storage medium can be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, an apparatus, or a suitable combination thereof.A non-exhaustive list of computer-readable storage media may include: a portable computer floppy disk, a hard disk drive (HDD), a solid-state drive (SSD), a read-only memory (ROM), a 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 of the foregoing. For the purposes of this document, a computer-readable storage medium is, for example, a tangible medium that stores a program for use by or in conjunction with a command-execution system or device.

[0052] The computer program code for executing operations for aspects of these provisions may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java™, Smalltalk, C++, or similar, and conventional procedural programming languages ​​such as the programming language "C" or similar. 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 the remote computer or server. In the latter case, the remote computer may be connected to the user's computer via a network comprising a local area network (LAN) or a wide area network (WAN), or the connection may be established with an external computer (e.g., a server).via the Internet with the help of an Internet service provider).

[0053] The terms "one" and "an," as used here, are defined as one or more than one. The term "multiple," as used here, is defined as two or more than two. The term "another," as used here, is defined as at least one other or more. The expressions "including" and / or "with" used here are defined to encompass the following (i.e., open language). The expression "at least one of ... and ..." used here refers to and includes all possible combinations of one or more of the listed elements. For example, the phrase "at least one of A, B, and C" includes only A, only B, only C, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0054] The aspects contained herein can be embodied in other forms without deviating from the basic idea or the essential properties. Accordingly, reference should be made to the following claims and not to the preceding description to specify the scope of the present invention.

Claims

[1] Interface system, with: one or more processors; a memory that is communicatively coupled to the one or more processors and stores a control module containing instructions which, when executed by the one or more processors, cause the one or more processors to: Receiving, within an interface device, an initialization request for access to a test device, wherein the test device is connected to a bridge in the interface device via connecting pins; Queries from a memory within the interface device, of configuration information about the test device, which include at least a mapping of the connecting pins to the bridge; and Providing the configuration information to facilitate communication with the test device. [2] Interface system according to claim 1, wherein the control module comprises instructions to provide the configuration information including instructions for generating a mapping of the test device pins for communicating with the test device via the bridge and the connecting pins via a network connection. [3] Interface system according to claim 1, wherein the control module comprises instructions for emulating a wiring harness between multiple test devices, including the test device, which includes instructions for mapping connections using separate configuration information for the multiple test devices, which is queried from the memory of the interface device. [4] Interface system according to claim 3, wherein the control module comprises instructions for emulating the wiring harness, including instructions for emulating the wiring harness under multiple interface devices, including the interface device with the multiple test devices distributed across the multiple interface devices. [5] Interface system according to claim 4, wherein the control module comprises instructions for emulating the wiring harness, including instructions for managing the wiring harness using an edge service by: Queries to the multiple interface devices to retrieve configuration information for the multiple test devices that are to be virtually connected via the wiring harness, and Generating a cable tree mapping that identifies connections via appropriate interface devices for the multiple test devices in order to facilitate communication between the multiple test devices. [6] Interface system according to claim 4, wherein the control module comprises instructions for emulating the wiring harness, including instructions for emulating the wiring harness using a cloud service between multiple edge services, each of which communicates separately with multiple interface devices, wherein the control module comprises instructions for using the cloud service to emulate the wiring harness, including instructions for providing remote access to the interface devices via the cloud service. [7] Interface system according to claim 1, wherein the control module comprises instructions for providing the configuration information to facilitate communication with the test device, including instructions for facilitating 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 are connected to the test device. [8] Interface system according to claim 7, wherein the first device and the second device provide access to different components of the test device, and wherein the bridge connects the interface device to an external network. [9] Non-transitory computer-readable medium comprising instructions which, when executed by one or more processors, cause the one or more processors to: Receiving, in an interface device, an initialization request for access to a test device, wherein the test device is connected to a bridge in the interface device via connecting pins; Queries from a memory within the interface device, of configuration information about the test device, which include at least a mapping of the connecting pins to the bridge; and Providing configuration information to facilitate communication with the test device. [10] Non-transitory computer-readable medium according to claim 9, wherein the instructions for providing the configuration information include instructions for generating a mapping of the test device pins for communication with the test device via the bridge and the connecting pins via a network connection. [11] Non-transitory computer-readable medium according to claim 9, wherein the instructions for emulating a wiring harness between multiple test devices, including the test device, comprise instructions for mapping connections using separate configuration information for the multiple test devices, which is queried from the memory of the interface device. [12] Non-transitory computer-readable medium according to claim 11, wherein the instructions for emulating the wiring harness comprise instructions for emulating the wiring harness between multiple interface devices, including the interface device with the multiple test devices distributed across the multiple interface devices. [13] Non-transitory computer-readable medium according to claim 12, wherein the instructions for emulating the line harness comprise instructions for managing the line harness using an edge service by: Queries to the multiple interface devices to retrieve configuration information for the multiple test devices that are to be virtually connected via the wiring harness, and Generating a mapping that identifies connections via appropriate interface devices for the multiple test devices in order to facilitate communication between the multiple test devices. [14] Methods, with: Receiving an initialization request within an interface device for accessing a test device, wherein the test device is connected to a bridge in the interface device via connecting pins; Queries of configuration information about the test device from a memory within the interface device, which include at least a mapping of the connecting pins to the bridge; and Providing configuration information to facilitate communication with the test device. [15] Method according to claim 14, wherein providing the configuration information comprises generating a mapping of the test device pins for communication with the test device via the bridge and the connecting pins via a network connection. [16] Method according to claim 14, further comprising: Emulating a wiring harness between multiple test devices, including the interface device, by mapping connections using separate configuration information for each of the multiple test devices, queried from the interface device's memory. [17] Method according to claim 16, wherein the emulation of the wiring harness comprises emulating the wiring harness under multiple interface devices including the interface device, wherein the multiple test devices are distributed among the multiple interface devices. [18] Method according to claim 17, wherein emulating the wiring harness comprises managing the wiring harness using an edge service by Queries to the multiple interface devices to retrieve configuration information for the multiple test devices that are to be virtually connected via the wiring harness, and Generating a mapping that identifies connections via appropriate interface devices for the multiple test devices in order to facilitate communication between the multiple test devices. [19] Method according to claim 17, wherein emulating the wiring harness comprises emulating the wiring harness using a cloud service among multiple edge services, each of which communicates separately with multiple interface devices, the use of the cloud service to emulate the wiring harness includes providing remote access to the interface devices via the cloud service. [20] Method according to claim 14, wherein the provision of the configuration information to facilitate communication with the device comprises facilitating access to the device from the interface device, which is a first device, and an additional interface device, which is a second device, both of which are connected to the device, wherein the first device and the second device provide access to different components of the test device, the bridge connects the interface device to an external network.

Images