Method, apparatus and computer program for operating a modular test bench comprising at least one test module for testing a test object

Abstract

Embodiments of a method (300) for operating a modular test bench, wherein the modular test bench comprises at least one test module for testing a test object. The method (300) comprises receiving first information about a hardware modification of the test module and about a software modification and second information about a hardware modification of the test object and about a software modification (301). The method (300) further comprises determining whether a combination of the first information and the second information fulfills a predetermined criterion (302) and outputting a check signal, thereby enabling a use of the test bench if the combination of the first information and the second information fulfills the predetermined criterion (303).

Description

Technical Field

[0001] The present invention relates to a method, apparatus and computer program for operating a modular test bench, the modular test bench including at least one test module for testing test objects. Background Technology

[0002] Manufacturing electromechanical systems is a complex process involving numerous interconnected electronic components. It is crucial that not only do each component operate reliably in isolation, but they also interoperate flawlessly, as the electromechanical system as a whole must demonstrate certain standards to the user, for example, in terms of reliability, safety, and cybersecurity. This is particularly true in automotive engineering, where detailed testing involves numerous electromechanical systems comprised of multiple objects. Test execution is typically initiated via test benches composed of modular hardware that performs tests or runs test scenarios specific to the test object (i.e., the object under test). For example, the test object might be a vehicle's cruise control or parking assist system. The modularity of the test bench can be beneficial because it can be upgraded to support future test objects, or because not every possible test object requires support from every test bench.

[0003] However, in practice, it is often observed that test results for specific combinations of test benches and test objects are affected by errors. The causes of these errors can have different origins and are often not understood. Document US2016 / 0305853A1 describes a method for testing a computer implementation of an electromechanical system through testing in a test environment that interacts with a real and / or virtual electromechanical system. This method includes providing a test series with different test cases for different execution conditions, wherein the execution conditions are specified in a test configuration. The method also includes assigning test state values ​​from a set of predefined test state values ​​for each combination of test cases and test configurations based on an evaluation of the functionality of the electromechanical system in the corresponding test, and determining at least once, for further planning, execution, and / or evaluation of the test series: the relative test coverage of at least one state value in the generated test case configuration matrix; and / or the relative probability of improvement of the test coverage of at least one state value for the test cases and / or for the configuration. Therefore, the results of tests performed according to an environment constellation are given, and parameters for relative test coverage and the relative probability of improvement for test coverage are determined. Based on two parameters, system test execution for the test suite can be performed to achieve the highest possible test coverage of 100% for the combination of test cases and test configurations.

[0004] In addition to typical errors caused by functional defects in the electromechanical system itself, pseudo-errors also exist due to incompatible combinations between the test bench and the test object. It has been observed that pseudo-errors occur even when the test bench hardware is generally capable of testing the test object (also known as the device under test). There appears to be a need to improve the interoperability between the test bench and the test object. Summary of the Invention

[0005] This objective is achieved through the subject matter of any of the independent claims.

[0006] An embodiment of a method for operating a modular test bench includes receiving first information regarding hardware revisions and software revisions of a test module, and also receiving second information regarding hardware revisions and software revisions of a test object, wherein the test bench includes at least one test module for testing the test object. The method also determines whether a combination of the first and second information satisfies predetermined criteria. Furthermore, the method includes outputting a verification signal to enable the use of the test bench when the combination of the first and second information satisfies the predetermined criteria. The software revisions of the test bench and the test object are also included in a compatibility assessment, taking into account multiple additional sources of incompatibility and reducing the number of false errors. Therefore, the combination can be interoperated by means of the verification signal, as it ensures that interoperability does not generate unreliable test results. The verification signal distinguishes between approved and unapproved test benches used for a specific test object to be tested.

[0007] According to some embodiments of the present invention, if a combination of first and second information exists in a dataset, predetermined criteria for a method of operating a modular test bench are satisfied. This dataset includes interoperable combinations of hardware and software modifications of the test module and hardware and software modifications of the test object. The predetermined criteria are used to determine whether the test module can perfectly interoperate with the test object. Depending on the presence of compatible combinations of test modules and test objects in the dataset, the method outputs a verification signal that approves the test module to test the test object. Using the dataset allows for recording any large number of combinations of hardware and software modifications. Furthermore, the dataset can be distributed across different test bench locations to easily increase device interoperability across multiple test benches.

[0008] According to some embodiments of the invention, the method for operating a modular test bench further includes storing a dataset. By storing a dataset including first and second information, interoperability or approved combinations between the test module and the test object are accessible beyond a temporary time period. For example, if a new software modification for the test object exists, the user can edit the dataset at any time, enabling the stored dataset to be updated with new compatible combinations based on the added software modifications to the test object.

[0009] According to some embodiments of the invention, the method for operating a modular test bench further includes receiving and transmitting an interoperable combination of first and second information to and from an external entity. This method allows for the acquisition of information related to compatible hardware and software modifications, which may, for example, be collected in advance at the external entity. By transmitting data to the external entity, information related to compatible combinations between test modules and test benches can be collected and is globally accessible. Data management also allows for keeping collected data from all test benches connected to the external entity up-to-date by adding new compatible combinations or deleting outdated data.

[0010] According to some embodiments of the invention, the method further includes receiving information regarding corrections to the data interface between the test bench and the test object, as well as information regarding test events. The method also includes determining whether the combination of the data interface corrections and the information regarding the test events satisfies other predetermined criteria. Furthermore, the method includes outputting a verification signal to enable the use of the test bench when the data interface corrections and the information regarding the test events satisfy other predetermined criteria. The number of false errors can also be reduced by also considering the data interface corrections and test events, for example, to ensure that the interface can transmit data associated with the test events. Therefore, false errors can be avoided because the test bench can correctly map test events to the corresponding test objects.

[0011] According to some embodiments of the present invention, the method for operating a modular test bench further includes outputting a verification signal to prohibit the use of the test bench when the combination of first and second information does not meet predetermined criteria. In this way, invalid test execution based on incompatible or unapproved combinations of test modules and test objects can be avoided, because the prohibition verification signal prevents the test bench from interoperating with the test object. Undesirable use can be prohibited even if the user of the test bench is unaware of the compatibility or has not previously approved the combination.

[0012] Embodiments of an apparatus for a modular test bench (wherein the modular test bench includes at least one test module for testing a test object) include an input interface configured to receive first information regarding hardware modifications and software modifications of the test module, and second information regarding hardware modifications and software modifications of the test object. Furthermore, evaluation logic is configured to determine whether a combination of the first and second information satisfies predetermined criteria. Additionally, an output interface is configured to output a verification signal, thereby enabling the use of the test bench when the combination of the first and second information satisfies the predetermined criteria. Software modifications to the test bench and the test object are also included in a compatibility assessment, taking into account multiple additional sources of incompatibility and reducing the number of false errors. Therefore, the combination can be interoperated by means of the verification signal, as it ensures that interoperability does not generate unreliable test results. The verification signal distinguishes between approved and unapproved test benches used for a specific test object to be tested.

[0013] According to some embodiments of the present invention, if a combination of first and second information exists in a dataset, predetermined criteria for a device for a modular test bench are satisfied. This dataset includes interoperable combinations of hardware and software modifications of test modules and hardware and software modifications of test objects. The predetermined criteria are used to determine whether a test module can perfectly interoperate with a test object. Depending on the presence of compatible combinations of test modules and test objects in the dataset, the method outputs a verification signal that approves the test module to test the test object. Using the dataset allows for recording any large number of combinations of hardware and software modifications. Furthermore, the dataset can be distributed across different test bench locations to easily increase device interoperability across multiple test benches.

[0014] According to some embodiments of the invention, the apparatus for a modular test bench further includes a memory in which a dataset has been stored. By storing the dataset, which includes first and second information, interoperability or approved combinations between the test module and the test object are accessible beyond a temporary time period. For example, if a new software modification for the test object exists, the user can edit the dataset at any time, allowing compatible combinations based on the new software modification to be added to the existing dataset.

[0015] According to some embodiments of the invention, the apparatus for a modular test bench further includes a management interface configured to receive and transmit interoperable combinations of first and second information to and from an external entity. The management interface allows access to information relating to compatible hardware and software modifications, which may, for example, be collected in advance by the external entity. By transmitting data to the external entity, information relating to compatible combinations between test modules and test benches can be collected and is globally accessible. Data management also allows keeping collected data from all test benches connected to the external entity up-to-date by adding new compatible combinations or deleting outdated data.

[0016] According to some embodiments of the invention, the input interface of the apparatus for the modular test bench is further configured to receive information regarding modifications to the data interface between the test bench and the test object, as well as information regarding test events. Evaluation logic is further configured to determine whether the combination of the data interface modifications and the information regarding test events satisfies other predetermined criteria. Furthermore, the output interface is configured to output a verification signal, thereby enabling the use of the test bench when the data interface modifications and the information regarding test events satisfy other predetermined criteria. The number of false errors can also be reduced by also considering the data interface modifications and test events, for example, ensuring that the interface can transmit data associated with the test events. Therefore, false errors can be avoided because the test bench can correctly map test events to the corresponding test objects.

[0017] According to some embodiments of the present invention, the output interface of the device for the modular test bench is further configured to output a verification signal, thereby prohibiting the use of the test bench when the combination of the first and second information does not meet predetermined criteria. In this way, invalid test execution based on incompatible or unapproved combinations of test modules and test objects can be avoided, because interoperability between the test bench and the test object is not permitted by disabling the verification signal. Undesirable use can be prohibited even if the user of the test bench is unaware of the compatibility or has not previously approved the combination.

[0018] Embodiments of the modular test bench including the specified apparatus also include a data interface configured to connect to and transmit data to the test object. The apparatus is implemented directly within the modular test bench, allowing the compatibility of the test bench with respect to the test object to be determined and communicated without the need for additional equipment. The test bench can directly receive second information about the test object via the implemented apparatus, enabling immediate determination of incompatibility between the test bench and the test object. Therefore, the test bench approves or disapproves by using inherent verification signals for testing the test object.

[0019] According to some embodiments of the invention, the data interface of the modular test bench is configured to connect to a vehicle. The vehicle is an example of an electromechanical system comprising complex electronic components, each of which will be tested by the test bench. By connecting the data interface to the vehicle, test scenarios can be sent to the test subject to examine the functionality of each component of the vehicle.

[0020] An embodiment of a computer program having program code that, when executed on a programmable processor, performs a method according to the previously described method for operating a modular test bench, wherein the test bench includes at least one test module for testing a test object. The computer program provides program code having the specified method, which can be implemented in software on any device. Exemplarily, any device can be a test bench, a test object, or a device for an external device. In this way, the user has the flexibility to implement software having the specified method, such as software used only for advanced test benches simulating complex test scenarios, such as virtual testing of a test object that has been previously examined through simple testing. Attached Figure Description

[0021] The following are some examples of methods and / or apparatuses described by way of example only and with reference to the accompanying drawings, wherein...

[0022] Figure 1 The illustration shows an embodiment of an apparatus and a test object for a modular test bench, wherein the modular test bench includes at least one test module.

[0023] Figure 2 The illustration shows an embodiment of the modular test bench.

[0024] Figure 3 The illustration shows a flowchart of an embodiment of a method for operating a modular test bench. Detailed Implementation

[0025] Various exemplary embodiments will now be described more fully with reference to the accompanying drawings, some of which illustrate exemplary embodiments. In the drawings, the thickness of lines, layers, or regions may be exaggerated for clarity.

[0026] Accordingly, while the other examples are capable of various modifications and alternatives, some specific examples are shown in the accompanying drawings and will be described in detail thereafter. However, this detailed description does not limit the other examples to the specific forms described. The other examples may cover all modifications, equivalents, and alternatives within the scope of this disclosure. Identical or similar figures throughout the description of the drawings denote similar or analogous elements that, when compared with each other, may be implemented identically or in modified forms while providing the same or similar functionality.

[0027] It will be understood that when an element is said to be "connected" or "coupled" to another element, the element may be directly connected or coupled via one or more intermediate elements. If "or" is used to combine two elements A and B, this will be understood to disclose all possible combinations unless otherwise explicitly or implicitly defined, i.e., only A, only B, and A and B. Alternative terms for the same combination are "at least one of A and B" or "A and / or B". The same applies, with appropriate modifications, to combinations of more than two elements.

[0028] The terminology used herein for the purpose of describing particular examples is not intended to limit other examples. Whenever the singular form such as “a,” “an,” and “the” is used and the use of a single element is not explicitly or implicitly defined as mandatory, other examples may use multiple elements to achieve the same functionality. Similarly, when functionality is subsequently described as being implemented using multiple elements, other examples may use a single element or processing entity to achieve the same functionality. It will be further understood that the terms “comprises” or “comprising” or “includes” when used specify the presence of the stated feature, integer, step, operation, process, action, element, and / or component, but do not preclude the presence or addition of one or more other features, integers, steps, operations, processes, actions, elements, components, and / or any grouping thereof.

[0029] Unless otherwise defined, all terms in this document (including technical and scientific terms) are used in their usual meaning in the field to which the examples belong.

[0030] Figure 1 The illustration shows an embodiment of an apparatus 100 for a modular test bench 110, wherein the modular test bench 110 comprises at least one test module 111a-111c for testing test objects 120a or 120b. The modularity of the test bench 110 is visualized by a plurality of slots or frames, which may include test modules 111a-111c (shown as shaded lines) or may be empty (shown as unfilled frames 111d-111g).

[0031] In this embodiment, test objects 120a and 120b are subsystems of vehicle 121, but any other electromechanical system can also be considered. To test the functionality of the test objects 120a and 120b, a test bench 110 with test modules 111a-111c is used. Individual modules of the test bench can be used to communicate with and test a specific test object 120a or 120b (e.g., a parking assist system), or they can be used to communicate with a group of test objects 120a and 120b, enabling the test bench 110 to test all objects 120a and 120b within a group. The compatibility between the test modules 111a-111c of the test bench 110 and the test objects 120a or 120b may depend on hardware and software modifications for each test module 111a-111c (hereinafter referred to as first information 102) and on hardware and software modifications for the test objects 120a or 120b (hereinafter referred to as second information 103). The compatibility between test modules 111a-111c of test bench 110 and test objects 120a or 120b can be checked through embodiments of device 100. The device processes first information 102 and second information 103 and outputs a verification signal to enable the use of test bench 110 when an interoperable combination between test object 120a or 120b and test modules 111a-111c has been approved. Approval can be assumed if the combination of first information 102 and second information 103 meets predetermined criteria. In some examples, device 100 may have access to a dataset that includes interoperable combinations between hardware and software modifications of the test modules and hardware and software modifications of test objects 120a or 120b, and if the combination of first information 102 and second information 103 already exists in the dataset, then predetermined criteria are met.

[0032] In this exemplary scenario, the compatibility of test modules 111a-111c may be checked by device 100, which then enables modular test bench 110 to connect to and transmit data to the corresponding test object 120a or 120b for test execution. Therefore, the number of errors caused by incompatible combinations of test modules 111a-111c with test objects 120a and 120b is reduced because test bench 110 cannot perform tests on test objects 120a or 120b that have not yet been approved as compatible. Thus, the time-consuming and costly process generated by redundant test execution can be avoided.

[0033] In the illustrated example, device 100 is schematically shown to include an input interface 101 configured to receive signals via... Figure 1The first information 102 is represented by the symbol X. The first information 102 includes hardware and software corrections for one or all test modules 111a-111c. The input interface 101 is also configured to receive the second information 103 represented by the symbol Y, which includes hardware and software corrections for test object 120a or 120b. The first information 102 of test modules 111a-111c and the second information 103 of test object 120a or 120b are processed by the evaluation logic 104 of the device 100. By way of example, the processing of the first information 102 and the second information 103 is represented by a function f[X,Y] that depends on the parameters of the first information 102 and the second information 103. The evaluation logic 104 is configured to determine whether the combination of the first information 102 and the second information 103 satisfies a predetermined criterion. If the predetermined criterion is satisfied by the combination of the first information 102 and the second information 103, the evaluation logic 104 outputs a verification signal via the output interface 105, thereby enabling the use of the test bench 110. The verification signal enables the complete test bench 110 to operate or, alternatively, only the individual test modules 111a-111c of the modular test bench 110 to operate.

[0034] Figure 1 The vehicle 121 shown is an example for an electromechanical system comprising multiple technical components that are manufactured individually and subsequently assembled into a complex end product. Multiple components with various hardware and software modifications are combined into an individual electromechanical system with defined specifications. Each component may correspond to test objects 120a and 120b, whose functionality will be tested. The presence of individual test objects 120a and 120b may be subject to the requirements of different test benches 110 or dedicated modules that will exist in a modular test bench. Using embodiments of device 100, multiple possible combinations between test objects 120a and 120b and test bench 210 can be considered to distinguish between approved and unapproved combinations of test benches and test objects.

[0035] To better understand the function of device 100, specific examples are discussed below, but this is not to limit the services and capabilities of the inventive device 100 to this embodiment. Figure 1In an embodiment, an example of a test subject might be the adaptive lighting 120a of a vehicle 121 to be tested by test events generated by test modules 111a-111c. To test the functionality of the adaptive lighting 120a of the vehicle 121, a test bench 110 may be provided, which is generally suitable for testing any type of headlight, such as adaptive or conventional headlights. For this purpose, the modular test bench 110 may include three test modules 111a-111c that are generally available for testing headlights. The device 100 can be used to identify which of the three test modules 111a-111c might be appropriate for testing the adaptive lighting 120a. Via input interface 101, the device 100 receives first information 102 regarding hardware and software modifications of the test modules 111a-111c, and second information 103 regarding hardware and software modifications of the adaptive lighting 120a. The evaluation logic 104 implemented in device 100 determines whether a combination of first information 102 and second information 103 of adaptive lighting 120a exists in the dataset for each test module 111a-111c.

[0036] The dataset includes an interoperable combination of hardware and software modifications for test modules 111a-111c and hardware and software modifications for test object 120a. Embodiments of device 100 may also include a memory 108 in which the dataset is stored. Typically, memory 108 may be any manual or electronic data collection that is available, searchable, downloadable, recallable, etc., such as residing on a server, on a storage device, in a list, chart, Excel spreadsheet, electronic document, data program, online or offline document, etc. The dataset may also be accessible via verbal communication, reporting, dictation, etc. Optionally, the dataset may also include information relating to the inherent type of hardware and software, interfaces, inherent drivers, updates, upgrades, etc.

[0037] according to Figure 1In the embodiment shown, the output interface 105 of device 100 outputs a verification signal, thereby enabling test module 111b for use with adaptive lighting 120a. Furthermore, the output interface 105 of device 100 is configured to output a verification signal, thereby disabling the use of test bench 110 when the combination of first information 102 and second information 103 does not meet predetermined criteria. In the illustrated example, device 100 outputs a verification signal to disable test modules 111a and 111c because the combination of the first information 102 of each test module 111a and 111c and the second information 103 of the adaptive lighting 120 of vehicle 121 is not in the dataset. This may occur, for example, because test module 111a or 111c operates with outdated software for general headlights, while the adaptive lighting software is up-to-date. Another example of incompatibility may involve the interface between test module 111a or 111c and test object 120a, as they do not belong to the same technology type or level. Therefore, test module 111b is recognized by device 100 as compatible for effectively testing the test object 120a. The remaining modules 111a and 111c are disabled because test events cannot be mapped to test object 120a and are expected to cause errors.

[0038] Embodiments of device 100 also include a management interface 106 configured to receive and transmit interoperable combinations of first information 102 and second information 103 to and from external entity 109. Management interface 106 can be used to receive information representing predetermined criteria given in the external dataset. The criteria received by management interface 106 can determine the type of output verification signal based on the operation of evaluation logic 104. In the illustrated example, management interface 106 receives all compatible combinations of test modules and corresponding test objects, in this example, test module 111b, because test modules 111a and 111c have been disabled for testing the adaptive lighting 120a of vehicle 121. This information transmitted via management interface 106 prompts evaluation logic 104 to send a verification signal for test module 111b, thereby enabling test execution on test object 120a.

[0039] Furthermore, management interface 106 is configured to transmit data to any external entity 109. In the illustrated example, management interface 106 can transmit data containing information related to interoperable combinations of test modules and test objects to an external server. For example, information on compatible combinations of test module 111b and adaptive lighting 120a is transmitted to the external server, allowing the server to depict all compatible test executions related to software and hardware modifications of the test modules and test objects. The device can also transmit new combinations of test modules and test objects not present in the dataset. For example, if test events for a test object are mapped by an unproven test module, a user can evaluate new combinations of test objects and test modules related to errors arising from test executions. Thus, considering new interoperable combinations between test modules and test objects, these combinations can be transmitted to an external server via the management interface. Using device 100, the server can be kept up-to-date and easily accessible to registered users planning to select appropriate test modules for pending test objects.

[0040] External entity 109 may be of any type used to receive, transmit, and / or store interoperable combinations, such as manual or electronic data merges. It is available, retrievable, downloadable, callable, transferable, printable, etc., and may reside on a server, in a list, table, Excel worksheet, electronic document, data program, online or offline document, etc. External entity 109 sending information related to the interoperable combination that is receivable by management interface 106 may include all types of data related to the inherent types of hardware and software, interfaces, inherent drivers, types of updates and upgrades, and generally information related to the effective test execution between the test modules of modular test bench 110 and test objects 120a or 120b.

[0041] In the example, signaling via interfaces such as the input interface 101, output interface 105, or management interface 106 of the device 100 for the modular test bench 110, or the data interface 107 between the test object and the test module, can be conventional via wired alternatives such as Universal Serial Bus (USB), Local Area Network (LAN) cable, fiber optic cable, etc., or wireless alternatives such as Wireless LAN (WLAN), Bluetooth, Near Field Communication (NFC), etc.

[0042] An example of the evaluation logic 104 could be any hardware or software that operates a mathematical function mapping the relationship between two sets, where each element of one set is assigned to an element of the other set. In this example, the two sets can be represented by inputs including first information 102 and second information 103 via input interface 101, predetermined criteria via management interface 106, and outputs depending on the input parameters. Implementations of the evaluation function 104 could include electronic components such as processors, transistors, diodes, etc.

[0043] Typically, device 100 is not limited to operating with information based on hardware and software modifications of test modules 111a-111c and test objects 120a and 120b, respectively. Device 100 may also be configured to operate with additional information based on data interface 107 and test events. Therefore, another embodiment of device 100 for a modular test bench 110 having test modules 111a-111c for testing said test objects 120a or 120b is considered, wherein input interface 101 is further configured to receive information regarding modifications to the data interface 107 between the test bench 110 and the test object 120, as well as information regarding test events. In this case, evaluation logic 104 may also be configured to determine whether the combination of the modification of data interface 107 and the information regarding test events satisfies additional predetermined criteria. Output interface 105 is configured to output a verification signal to enable the use of test bench 110 when the modification of data interface 107 and the information regarding test events satisfy additional predetermined criteria. In the illustrated example, regarding the brake assistant 120b of vehicle 121, vehicle 121 can also be tested. The brake assistant 120b can be tested by presenting a virtual simulation (including test scenarios of the surrounding environment) to vehicle 121. Test scenarios can include different test events, such as representing fast-moving highways, landscaped rural roads, etc. Therefore, multiple test events can exist for testing the brake assistant 120b. Depending on the type of brake assistant 120b, some test executions may be ignored because, for example, the data interface 107 of the camera system controlling the brake assistant 120b cannot receive and process all types of test events. Embodiments of device 100 may be able to receive information about test events via input interface 101 and determine via evaluation logic 104 whether the data interface 107 of the camera system and the visualized test events meet additional predetermined criteria. As an example, device 100 operates with three test events, including driving on a highway, driving at night, and driving by playing on the streets. According to predetermined criteria provided by an external server, device 100 determines that the combination of data interfaces of the braking assistant 120b's camera system is incompatible with some of the test events. For example, some test events may not be effectively mapped to the camera system because the surrounding environment is too dark, involving night driving, or moving objects such as children that are not detectable by the outdated camera system, or driving through playful streets. Therefore, device 100 appropriately disables two incompatible test events for test subject 120b by outputting a verification signal via the output interface. The dataset can also be evaluated by algorithms for further analysis. Analysis can provide information related to functional verification between the test bench module and the test subject. For example, functional verification can check whether the test bench module and / or the test subject function as expected or not.The application of analytical algorithms to datasets can be used to identify additional methods for compatible combinations between testbench modules and test objects according to specifications.

[0044] Typically, regarding functionality, a test bench tests the test object and also ensures that the test object functions as specified. Data sets that allow for interoperability can also be used to find inconsistencies between and within the functionality of the test object. Inconsistencies could be, for example, incorrect implementations or incorrect specifications. On the one hand, it can be assumed that the hardware and / or software configuration of the test module is incompatible with the test object. On the other hand, it can be assumed that the test module and the test object should never be compatible, even with updated test configurations.

[0045] To better understand, the specified embodiments relate to the automotive industry as an example of an electromechanical system, which includes various technical components, each of which is individually tested to authorize safety standards for end-product users. Typically, device 100 can be used in all types of transportation, such as electric bicycles, motorcycles, quad bikes, trucks, airplanes, helicopters, unmanned aerial vehicles (UAVs), etc. Furthermore, the use of device 100 for testing the modular test benches 111a-111c for the test objects 120a and 120b is not limited to the transportation field but is also applicable to all types of electromechanical systems or electrical units. To name just a few examples, this could include fields that incorporate technical components and / or integrate technical components into complex test objects, as it can exist in information technology, entertainment electronics, the mobile phone industry, medical engineering, manufacturing engineering, logistics processes, drive tools, home appliances, etc.

[0046] Figure 2 The illustration shows an embodiment of a modular test bench 210 for testing a test object 220 of a vehicle 221. The test bench 210 includes a device 200 and a data interface 207 configured to connect to and transmit data to the test object 220. The device 210 includes an input interface 201 configured to receive first information 202 regarding hardware and software modifications of test modules 211a-211e, and second information regarding hardware and software modifications of the test object 220. The device 200 also includes evaluation logic 204 configured to determine whether a combination of the first information 202 and the second information 203 satisfies predetermined criteria. Furthermore, the device 200 includes an output interface 205 configured to output a verification signal, thereby enabling the use of test modules 211a-211e when the combination of the first information 202 and the second information 203 satisfies predetermined criteria. As previously described... Figure 1The embodiment of the test bench 200, which already implements the device 200 described herein, can be directly connected to the test object 220 and transmit data to it. As an example, prior to the use of test modules 211a-e for the test object 220, test execution according to a compatible combination of first information 202 and second information 203 is automatically enabled or disabled by the device 200. The test bench 210, including the device 200, is kept up-to-date via a management interface 206, which communicates with external entities to receive and transmit interoperable combinations of the first and second information.

[0047] Figure 3 A flowchart is shown, illustrating an embodiment of a method for operating a modular test bench 300, wherein the modular test bench includes at least one test module for testing a test object. Method 300 includes receiving first information regarding hardware and software modifications of the test module, and second information regarding hardware and software modifications of the test object, 301. Method 300 further includes determining whether a combination of the first and second information satisfies a predetermined criterion, 302, and outputting a verification signal, thereby enabling the use of the test bench 303 when the combination of the first and second information satisfies the predetermined rule.

[0048] Another embodiment of the method can improve test bench and test infrastructure management through automatic configuration mapping of the test bench, including cloud interface software. Further embodiments of the method may represent cloud-based test infrastructure and test bench management with automatic comparison between test configurations and test object requirements. The configuration mapping implementation may be an embodiment of a device with additional equipment or tools that can be inserted into a modular test bench, for example, to receive and / or store first information regarding hardware and software modifications of the test module, with or without predetermined criteria.

[0049] Predetermined criteria may have certain specifications and are met as the hardware and software of the test bench continuously adapt to the technology of the hardware and software of the test object (this can be done by updating or upgrading the configuration). This may require a continuous comparison between the test bench capabilities and the capabilities required by the test object. Therefore, prior to a continuous comparison between the test bench capabilities and the requirements of the test object, the definitions of the criteria relevant to the comparison should be determined and continuously reviewed.

[0050] In the case of automakers, this may require standardizing those guidelines throughout the automaker's organization, training personnel, and establishing and maintaining rigorous test recipes and test bench configurations.

[0051] Because test benches are often sourced from different vendors, test recipes and test bench configurations increase, making it increasingly difficult to ensure compatibility, repeatability, and reproducibility. Unfortunately, due to the often proprietary implementations of Electronic Control Units (ECUs) in the automotive industry, corresponding test bench configurations are usually also specifically configured for the needs of those ECUs. Therefore, changes to hardware and software configurations to also match with other ECUs can adversely affect the original test setup for a specific purpose. The readiness of the test benches used for testing remains at an unmanageable level. Consequently, many testing problems only suddenly emerge once the test subject has been inserted into the test system. In addition to the already mentioned complexity of manipulating test recipes to test bench configurations, another significant problem exists: firstly, new test recipes are no longer deterministic but are generated as the result of cloud-based simulations of driving environments and conditions. These generated scenarios are connected to the test bench via interfaces, involving software that maps those scenarios to the corresponding test bench configuration. Even if this software can utilize an Application Programming Interface (API), data exchange between the virtual test subject or virtual environment and the test module may require additional transfer functions to transform timestamps from the virtual world to real-time scenarios. In particular, limitations in simulation capabilities can emerge and persist here. Therefore, this underscores the need to preserve corresponding test scenarios for actual hardware implementations to avoid spurious successes or failures. The software implementation may be proprietary, validated and verified only for specific testbench hardware and software configurations. Therefore, this software always requires review for compatibility with individual testbench configurations.

[0052] Embodiments of this device can transfer their configuration and ensure test capabilities to the test infrastructure cloud. Furthermore, leveraging the availability of local and global testbed information, it may be possible to improve test infrastructure management and logistics through embodiments of the invention. By comparing the local test infrastructure with the test requirements of a vehicle platform also stored in the cloud, test hardware and software gaps can be automatically identified. Depending on the testbed hardware and software, plug-and-play configuration updates within embodiments of the device may be possible, simplifying many tasks when changing testbed hardware. Furthermore, misuse can be prevented, as hardware changes will indicate unverified configurations made by the device. Additionally, this allows for overall traceability of test conditions, transfer to a digital twin, and reloading capabilities related to validation years later. This allows for simulating test configuration changes before implementation and may benefit improved planning and problem-solving.

[0053] Furthermore, embodiments of the device can provide storage of test bench configurations within test modules for integration into each modular test bench. Additionally, it can store published modular test bench configurations related to predetermined criteria. Embodiments of the device can also provide automatic comparisons between current and published test bench configurations related to predetermined criteria, and indicate mismatches and incompatibilities between test events, test modules of the test bench, and test objects. Embodiments of the device can also store and control information based on modular test bench configurations, published test bench configurations related to predetermined criteria, and automatic comparisons of the two within the test infrastructure cloud. Embodiments of the device can allow domain computer centers (DCCs) according to 2019 / 0592 (K26902) to potentially be used as important test bench components. In this way, automatic configuration mapping according to the principles described above will be more simplified for potential future test objects integrated into the DCC according to 2019 / 0592 (K 26902). This implementation allows for the creation of synergies between the test infrastructure and test object development, including virtual prototyping, which can lead to cost savings.

[0054] The aspects and features mentioned and described together with one or more of the previously detailed examples and figures may also be combined with one or more other examples in order to replace similar features of other examples or to introduce additional features to other examples.

[0055] Examples may also be or relate to computer programs having program code that, when executed on a computer or processor, performs one or more of the methods described above. The steps, operations, or processes of the various methods described above may be performed by a programmed computer or processor. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor-, or computer-readable and encode machine-executable, processor-executable, or computer-executable programs of instructions. The instructions execute or cause some or all of the actions performed by the methods described above. Program storage devices may include, for example, digital memory, magnetic storage media (such as disks and tapes), hard disk drives, or optically readable digital data storage media. Further examples may also cover computers, processors, or control units programmed to perform the actions of the methods described above, or (field-programmable) logic arrays ((F)PLAs) or (field-programmable gate arrays ((F)PGAs) programmed to perform the actions of the methods described above.

[0056] This description and accompanying drawings are solely for illustrating the principles of this disclosure. Furthermore, all examples described herein are generally intended for illustrative purposes only to aid the reader in understanding the principles of this disclosure and the concepts contributed to the art by one or more inventors. All statements herein recounting the principles, aspects, and examples of this disclosure, as well as specific examples thereof, are intended to include their equivalents.

[0057] A function block, denoted as "a component for...", which performs a certain function, can also represent a circuit configured to perform that function. Therefore, "a component for a certain aspect" can be implemented as "a component configured or suited to a certain aspect", such as a device or circuit configured or suited to a corresponding task.

[0058] The functions of the various elements shown in the accompanying drawings, including those labeled "components," "components for providing signals," "components for generating signals," etc., can be implemented in the form of dedicated hardware such as "signal providers," "signal processing units," "processors," "controllers," etc., as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functionality can be provided by a single dedicated processor, a single shared processor, or multiple individual processors (some or all of which may be shared). However, the terms "processor" or "controller" are not currently limited to hardware specifically capable of executing software, but can include digital signal processor (DSP) hardware, network processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage devices. Other conventional or custom hardware may also be included.

[0059] Block diagrams, for example, can illustrate high-level circuit diagrams that implement the principles of this disclosure. Similarly, flowcharts, simplified flowcharts, state transition diagrams, pseudocode, etc., can represent various processes, operations, or steps, which can be represented substantially in a computer-readable medium and therefore executed by a computer or processor, whether or not such a computer or processor is explicitly shown. The methods disclosed in this specification or in the claims can be implemented by means of means having components for each of the corresponding actions for performing these methods.

[0060] It should be understood that the disclosure of multiple actions, processes, operations, steps, or functions in this specification or claims is not to be construed as being in a particular order, for example, for technical reasons, unless otherwise explicitly or implicitly stated. Therefore, the disclosure of multiple actions or functions is not intended to limit these actions or functions to a particular order, unless such actions or functions are not interchangeable for technical reasons. Furthermore, in some examples, a single action, function, process, operation, or step may include or be decomposed into multiple sub-actions, sub-functions, sub-processes, sub-operations, or sub-steps. Such sub-actions may be included, and include, the disclosed portion of that single action, unless explicitly excluded.

[0061] Furthermore, the following claims are thus incorporated into the detailed description, wherein each claim may stand alone as a separate example. While each claim may stand alone as a separate example, it should be noted that—although a dependent claim may refer in the claims to a specific combination of one or more other claims—other examples may also include combinations of the subject matter of that dependent claim with the subject matter of each of the other dependent or independent claims. Such combinations are explicitly presented herein unless stated otherwise. Furthermore, it is intended that the features of a claim be included in any other independent claim, even if that claim is not directly dependent on said independent claim.

[0062] Reference Symbol List

[0063] 100 devices

[0064] 101 Input Interface

[0065] 102 First Information

[0066] 103 Second Information

[0067] 104 Evaluation Logic

[0068] 105 Output Interface

[0069] 106 Management Interface

[0070] 107 Data Interface

[0071] 108 memory

[0072] 109 External Entities

[0073] 110 Modular Test Stand

[0074] 111a-c Test Module

[0075] 120a Test object: Adaptive lighting

[0076] 120b Test Subject: Brake Assist

[0077] 121. Means of transportation

[0078] 200 devices

[0079] 201 Input Interface

[0080] 202 First Information

[0081] 203 Second Information

[0082] 204 Evaluation Logic

[0083] 205 Output Interface

[0084] 206 Management Interface

[0085] 207 Data Interface

[0086] 210 Modular Test Stand

[0087] 211a-d test module

[0088] 220 test subjects

[0089] 221. Means of transport

[0090] 300 A method for operating a modular test bench, wherein the modular test bench includes at least one test module for testing a test object.

[0091] 301 Receives first information regarding hardware modifications and software modifications to the test module, and receives second information regarding hardware modifications and software modifications to the test object.

[0092] 302 Determine whether the combination of the first and second information satisfies predetermined criteria.

[0093] 303 outputs a verification signal, thereby enabling the use of the test bench when the combination of the first and second information meets predetermined criteria.

Claims

1. A method (300) for operating a modular test bench, the modular test bench including at least one test module for testing a test object, the method comprising: Receive first information regarding hardware corrections and software corrections for the test module, and receive second information regarding hardware corrections and software corrections for the test object (301). Determine whether the combination of the first information and the second information satisfies a predetermined criterion (302). as well as Output a verification signal to enable the use of the test bench (303) when the combination of the first information and the second information satisfies the predetermined criterion, wherein the predetermined criterion is satisfied if the combination of the first information and the second information exists in a dataset, the dataset including interoperable combinations between hardware and software modifications of the test module and hardware and software modifications of the test object.

2. The method of claim 1, further comprising: Store the dataset.

3. The method of claim 1 or 2, further comprising: Interoperable combination of receiving and transmitting first and second information between external entities.

4. The method of claim 1 or 2, further comprising: Receive information regarding corrections to the data interface between the test bench and the test object, and information regarding test events; Determine whether the combination of the modification of the data interface and the information about the test event satisfies other predetermined criteria; as well as The verification signal is output so that the use of the test bench is enabled when the correction of the data interface and the information about the test event meet the additional predetermined criteria.

5. The method of claim 1 or 2, further comprising: The verification signal is output so as to prohibit the use of the test bench when the combination of the first information and the second information does not meet the predetermined criteria.

6. An apparatus (100) for a modular test bench (110), the modular test bench including at least one test module (111a-c) for testing test objects (120a, 120b), the apparatus (100) comprising: An input interface (101) is configured to receive first information (102) regarding hardware corrections and software corrections for the test modules (111a-c) and second information (103) regarding hardware corrections and software corrections for the test objects (120a, 120b). Evaluation logic (104), configured to determine whether the combination of the first information (102) and the second information (103) satisfies a predetermined criterion; and An output interface (105) is configured to output a verification signal that enables the use of the test bench (110) when the combination of the first information (102) and the second information (103) satisfies the predetermined criterion, wherein the predetermined criterion is satisfied if the combination of the first information (102) and the second information (103) exists in a dataset, the dataset including an interoperable combination of hardware and software modifications of the test modules (111a-111c) and hardware and software modifications of the test objects (120a, 120b).

7. The apparatus (100) of claim 6 further comprises: A memory (108) in which the dataset has been stored.

8. The apparatus (100) as claimed in claim 6 or 7, further comprising: A management interface (106) is configured to receive and transmit an interoperable combination of first information (102) and second information (103) to and from an external entity (109).

9. The apparatus (100) as claimed in claim 6 or 7, in, The input interface (101) is further configured to receive information regarding modifications to the data interface (107) between the test bench (110) and the test objects (120a, 120b) and information regarding test events, wherein the evaluation logic (104) is further configured to determine whether the combination of the modifications to the data interface (107) and the information regarding the test events satisfies additional predetermined criteria; and The output interface (105) is further configured to output the verification signal, thereby enabling the use of the test bench (110) when the correction of the data interface (107) and the information about the test event meet the additional predetermined criteria.

10. The apparatus (100) as claimed in claim 6 or 7, wherein The output interface (105) is also configured to output a verification signal, thereby prohibiting the use of the test bench (110) when the combination of the first information (102) and the second information (103) does not meet the predetermined criteria.

11. A modular test bench (210), comprising: The apparatus (200) as described in any one of claims 6 to 10; as well as A data interface (207) is configured to connect to the test object (220) and transmit data to it.

12. The modular test bench (210) as described in claim 11, wherein, The data interface (207) is also configured to connect to a vehicle (221).

13. A computer program product having program code that, when executed on a programmable processor, performs the method as claimed in any one of claims 1 to 5.

Images