System and method for managing test bench for cross-domain test

Abstract

To provide a system, method, and device for facilitating provision and / or utilization of a test bench for a cross-domain test for testing software of an embedded system.SOLUTION: A method may be implemented by at least one processor and may include the steps of: obtaining a test bench configuration associated with software; obtaining information of a plurality of test artifacts associated with the test bench configuration; and generating, based on the plurality of test artifacts, a test bench associated with a cross-domain test. The software of an embedded system comprises an on-vehicle electronic control unit (ECU).SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] Systems and methods consistent with exemplary embodiments of the present disclosure relate to test bench management, and more particularly, to systems and methods for facilitating the provisioning and utilization of one or more test benches for cross-domain testing.

Background Art

[0002] A test bench in software testing can refer to information or parameters such as a set of tools, procedures, functional configurations, equipment, etc. that enable a test to be executed under desired conditions, environments, or settings when compiled or utilized.

[0003] In some situations, a test bench can provide or define various test requirements, such as, among other things, the hardware resources and / or software resources needed to provide a virtual environment that simulates the actual environment in which software is introduced and tested.

[0004] The resources used in a test bench for software testing can include requirements on hardware resources, such as requirements on hardware components with which the software can interact in order for the software to function properly. For example, in a vehicle - embedded system, the hardware resources can include one or more physical electronic control units (ECUs) with which the target ECU (e.g., the ECU under test) interoperates, one or more servers that host the relevant data or information, and / or the like. In addition to hardware resources, a test bench for software testing can also include requirements regarding software resources. For example, in a vehicle - embedded system, the software resources can include one or more virtualized or emulated ECUs with which the target ECU interoperates, one or more operating systems for executing the tests, and / or the like.

[0005] Put simply, the relationship between the test bench and the resources in software testing is that the test bench provides or defines the resources necessary for executing tests to evaluate the performance of the software under various conditions. By simulating the actual environment or conditions in which the software will be introduced, the test bench helps to identify and address any problems or defects in the software before the software is introduced into the actual production environment, verify the accuracy of the soundness of the software design, and the like. This helps to ensure that the software is reliable, functions well, and meets the requirements.

[0006] In this regard, the resources required for testing depend on the nature of the software to be tested and specific test requirements. For example, if the software to be tested requires a specific operating system or a specific hardware configuration, the test bench is required to include information on said resources in order to effectively test the software. Furthermore, the test bench needs to be designed to accommodate the specific type of test to be executed, such as single-level testing, multi-level testing, etc. As an example, a test bench related to a Software-in-the-Loop (SIL) test environment may be different from a test bench related to a Hardware-in-the-Loop (HIL) test environment.

[0007] Considering the above, the test bench is required to be carefully configured and designed to ensure efficient and effective testing. Nevertheless, as described below, the provisioning and utilization of test benches for testing related vehicle-related software are restricted and inefficient and ineffective.

[0008] First, in the prior art, whenever the testing of a software component involves a specific hardware component (e.g., a specific physical ECU, etc.), the user is required to visit a specific test facility where the specific hardware component is introduced, couple the software component to the hardware component, configure the test bench accordingly, and then execute the test. Therefore, it takes time for the user to access and utilize the test bench as they need to physically move to a specific test facility before they can access the test bench.

[0009] Furthermore, since the hardware introduced into the test facility is limited and restricted to specific types or variants, the number of possible parallel tests is small, it is difficult to construct or configure a test bench on-site, and a test bench built for a specific vehicle variant cannot be used for other vehicle variants.

[0010] For example, the hardware resources of the test facility are physically fixed and are always introduced in a black box manner while the test is in progress (for example, a user using the test facility can secure most (if not all) of the resources within the test facility), so it is extremely difficult (if not impossible) for multiple users to use the test facility simultaneously, and it is also difficult (if not impossible) for a user to execute multiple tests simultaneously in the test facility. Therefore, whenever a user has multiple tests to execute and / or multiple users want to use the test facility, there is always a possibility of job collision problems, and the users have to take turns (such as making a reservation on a waiting list). However, this significantly delays the tests and ultimately delays the development of software (such as ECUs, etc.). Furthermore, the arrangement, coordination, and tests among users are managed manually, which is inefficient and burdensome for the users.

[0011] Furthermore, when specific software components (such as a specific type of virtual ECU, a specific operating system, etc.) are required but not available in the test facility, the user always has to request the test facility manager to obtain the specific software components, and the manager has to search for the requested software components and then obtain them. This not only causes further delays in software testing but also incurs additional costs (such as human resources, fees charged for obtaining the necessary software components, etc.).

[0012] Furthermore, test benches are typically introduced and provided in a test facility and are most often of a predefined, general-purpose nature. Thus, a user may need to frequently configure the test bench to meet the intended test requirements. Nevertheless, in the prior art, the user has to manually configure the provided test bench, which is time-consuming and may require the user to have a good technical understanding of the system in order to properly configure the test bench. In this regard, a user who does not have a good understanding or experience in configuring the test bench may not be able to configure the test bench efficiently and accurately, leading to inaccurate tests and potential human errors.

[0013] Provisioning and utilization of test benches become more difficult and complex when cross-domain testing is involved, which is the testing required when developing advanced or complex functions of vehicle systems (such as lane change assist, mobile smart key, etc.). This is because cross-domain testing involves testing multiple software components and hardware components across multiple systems, resulting in a significant number of components, users / stakeholders, test requirements, etc. being involved, which increases the dynamic nature in test bench configuration and the resources required to execute cross-domain testing.

[0014] In the prior art, it is overly difficult to appropriately and dynamically provide a test bench for securing resources for cross-domain testing. Instead, before setting up the test bench, it takes a significant amount of time to collect the necessary information and arrange the necessary software components / hardware components. Therefore, it takes time to prepare and execute cross-domain testing. Furthermore, every time a change occurs during cross-domain testing (e.g., software updates during testing, failures of hardware components, etc.), it is necessary to redesign or reset the test bench, which may further delay the testing and ultimately delay the software development. Additionally, the resources secured for cross-domain testing are such that the requirements in the resources are dynamic and can change continuously (or occasionally), so there is a possibility of overprovisioning (which can cause waste of resources) or underprovisioning (which can cause inefficient test execution and further delay in software development).

[0015] Considering the above, the approaches for provisioning and utilizing a test bench for cross-domain testing in the prior art are limited, inefficient, and burdensome to users. Ultimately, these can potentially increase the lead time from the system-on-chip (SoC) specification to the start of vehicle production (SOP). SUMMARY OF THE INVENTION

[0016] According to an embodiment, there are provided a method, a system, and a device for automatically managing one or more test benches for cross-domain testing for testing one or more software of a system. Specifically, for example, the method, system, apparatus, etc. of the exemplary embodiment can automatically acquire the necessary information and automatically provide one or more test benches as needed.

[0017] According to an embodiment, a method for managing a test bench for cross-domain testing of software of an embedded system may be provided. The method may be implemented by at least one processor of the system, and may include obtaining a test bench setting associated with the software, obtaining information on a plurality of test artifacts associated with the test bench setting, and generating a test bench associated with cross-domain testing based on the plurality of test artifacts.

[0018] According to an embodiment, obtaining a test bench setting may include receiving from a user one or more inputs defining the test bench, obtaining a component catalog including information on available test artifacts, determining, based on the one or more inputs, one or more test artifacts associated with the test bench defined by the user from among the available test artifacts, and constructing a test bench setting based on the determined one or more test artifacts.

[0019] According to an embodiment, the software of the embedded system may include an in-vehicle electronic control unit (ECU). Also, the plurality of test artifacts may include at least one software component, at least one hardware component, or a combination thereof. The at least one software component may include at least one virtual ECU, at least one emulated ECU, or a vehicle-related model, and the at least one hardware component may include at least one physical ECU. Further, at least a part of the plurality of test artifacts may be introduced at geographically different locations.

[0020] According to an embodiment, the method may further include introducing at least one software component based on a test bench, securing at least one hardware component based on the test bench, and creating a virtual vehicle model based on the at least one software component and the at least one hardware component. According to an embodiment, the method may further include generating a test rig for cross-domain testing based on the virtual vehicle model.

[0021] According to an embodiment, introducing at least one software component may include determining at least one resource requirement for introducing at least one software component based on the test bench, determining at least one node that meets the at least one resource requirement from among a plurality of nodes communicatively coupled to the system, and introducing at least one software component to the determined at least one node.

[0022] According to an embodiment, securing at least one hardware component may include determining at least one hardware resource requirement based on the test bench, determining at least one hardware component that meets the at least one hardware resource requirement from among a plurality of hardware components communicatively coupled to the system, and securing at least one hardware component.

[0023] According to an embodiment, creating a virtual vehicle model may include determining a relationship between at least one software component and at least one hardware component based on the test bench, and connecting the at least one software component to the at least one hardware component based on the determined relationship.

[0024] According to an embodiment, a system for managing a test bench for cross - domain testing of software of an embedded system is provided. The system may include at least one memory storage storing computer - executable instructions, and at least one processor communicatively coupled to the at least one memory storage and configured to execute computer - executable instructions for obtaining test bench settings associated with the software, obtaining information on a plurality of test artifacts associated with the test bench settings, and generating a test bench associated with cross - domain testing based on the plurality of test artifacts.

[0025] According to an embodiment, the at least one processor may be configured to execute computer - executable instructions for receiving one or more inputs defining the test bench from a user, obtaining a component catalog including information on available test artifacts, determining one or more test artifacts associated with the test bench defined by the user from among the available test artifacts based on the one or more inputs, and constructing test bench settings based on the determined one or more test artifacts, thereby obtaining the test bench settings.

[0026] According to an embodiment, the software of the embedded system may include an in - vehicle electronic control unit (ECU). Also, the plurality of test artifacts may include at least one software component, at least one hardware component, or a combination thereof. The at least one software component may include at least one virtual ECU, at least one emulated ECU, or a vehicle - related model, and the at least one hardware component may include at least one physical ECU. Further, at least a portion of the plurality of test artifacts may be introduced at geographically different locations.

[0027] According to an embodiment, at least one processor may be configured to execute computer-executable instructions for introducing at least one software component based on a test bench, securing at least one hardware component based on the test bench, and creating a virtual vehicle model based on the at least one software component and the at least one hardware component. Further, at least one processor may be further configured to execute computer-executable instructions for generating a test rig for cross-domain testing based on the virtual vehicle model.

[0028] According to an embodiment, at least one processor may be configured to execute computer-executable instructions for introducing at least one software component by determining at least one resource requirement for introducing at least one software component based on a test bench, determining at least one node that meets the at least one resource requirement from among a plurality of nodes communicatively coupled to the system, and introducing the at least one software component to the determined at least one node.

[0029] According to an embodiment, at least one processor may be configured to execute computer-executable instructions for securing at least one hardware component by determining at least one hardware resource requirement based on a test bench, determining at least one hardware component that meets the at least one hardware resource requirement from among a plurality of hardware components communicatively coupled to the system, and securing the at least one hardware component.

[0030] According to an embodiment, at least one processor may be configured to execute computer-executable instructions for creating a virtual vehicle model by determining a relationship between at least one software component and at least one hardware component based on a test bench and connecting the at least one software component to the at least one hardware component based on the determined relationship.

[0031] Additional aspects are described in part in the following description, are partially apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.

Brief Description of the Drawings

[0032] The features, advantages, and significance of exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings in which like reference numerals indicate like elements.

[0033]

Figure 1

[0034]

Figure 2

[0035]

Figure 3

[0036]

Figure 4

[0037]

Figure 5

[0038] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the embodiments. Additionally, one or more features or components of one or more embodiments may be incorporated in or combined with other embodiments (or one or more features of other embodiments). Further, in the description of the operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part), and the order of one or more operations may be switched.

[0039] Even if a particular combination of features is recited in the claims and / or disclosed herein, that combination is not intended to limit the disclosure of possible implementations. Indeed, many of those features may be combined in ways not specifically recited in the claims and / or disclosed herein. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0040] Any element, operation, or instruction used in this specification should not be construed as decisive or essential unless explicitly described as such. Also, as used in this specification, the articles "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more." When only one item is intended, the term "one" or similar language is used. Also, as used in this specification, terms such as "have," "having," "include," "including," etc. are intended to be open-ended terms without limitation. Further, the phrase "based on" is intended to mean "at least in part based on" unless explicitly described otherwise. Further, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0041] References throughout this specification to "one embodiment," "an embodiment," "a non-limiting preferred embodiment," or similar terms mean that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the solution. Thus, the phrases "in one embodiment," "in an embodiment," "in a non-limiting preferred one embodiment," and similar terms throughout this specification may all refer to the same embodiment, but not necessarily so.

[0042] Furthermore, the features, advantages, and characteristics of the present disclosure described may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, in view of the description herein, that the present disclosure may be practiced without using one or more of the particular features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in particular embodiments that may not be present in all embodiments of the present disclosure.

[0043] Exemplary embodiments consistent with the present disclosure provide a method, system, and apparatus for facilitating the provisioning and / or utilization of at least one test bench for cross-domain testing to test one or more software of an embedded system, such as one or more in-vehicle ECUs.

[0044] Specifically, the method, system, apparatus, etc. of the exemplary embodiments can automatically provide one or more test benches according to requirements. For example, the method, system, apparatus, etc. of the exemplary embodiments can automatically obtain one or more test bench settings and automatically generate one or more test benches based thereon. The one or more test bench settings can be associated with one or more user inputs that define the intended test bench, such as software components and / or hardware components necessary to test a specific software.

[0045] The generated one or more test benches can be provided to one or more utilization parties for further utilization to perform cross-domain testing. Alternatively or additionally, the method, system, apparatus, etc. of the exemplary embodiments can automatically create a virtual vehicle model based on the generated one or more test benches and utilize the virtual vehicle model to perform cross-domain testing. In some implementations, one or more test rigs can be generated based on the virtual vehicle model and the generated one or more test benches, and the one or more test rigs can be provided or utilized for cross-domain testing.

[0046] Accordingly, the methods, systems, apparatuses, etc. of the exemplary embodiments can continuously (or periodically) monitor the status of available test artifacts and resources, and generate and reconfigure one or more test benches as needed based on real-time or near-real-time status and test requirements. As a result, one or more test benches are provided and can be utilized on demand without geographical restrictions.

[0047] For this purpose, a user can remotely configure one or more conditions for defining the requirements for performing cross-domain tests, and the required test benches can be automatically and appropriately provided and configured in real-time or near-real-time without the user having to actually visit a test facility. Ultimately, the exemplary embodiments of the present disclosure enable more efficient software development, significantly reduce the user's burden, significantly reduce development time, and significantly reduce the costs and effort for planning visits to test facilities and business trips.

[0048] It is intended that the features, advantages, and significance of the above exemplary embodiments are only a part of the present disclosure and are not intended to be comprehensive or to limit the technical scope of the present disclosure. Further descriptions of the features, components, configurations, operations, and implementations of the exemplary embodiments of the present disclosure are provided below, along with their associated technical advantages and significance.

[0049] FIG. 1 is a block diagram of an exemplary system configuration 100 for managing (provisioning, utilization, etc.) a test bench for cross-domain testing according to one or more embodiments. As shown in FIG. 1, the system configuration 100 may include a test bench management system 110, a plurality of nodes 120-1 to 120-N, a network 130, and at least one utilization party 140.

[0050] Generally, the test bench management system 110 is communicatively coupled to a plurality of nodes 120-1 to 120-N (via network 130) and a usage party 140, interoperates with the plurality of nodes 120-1 to 120-N, and may be configured to provide a test bench (or one or more related information or data) to the usage party 140. An explanation of exemplary components that may be included in the test bench management system 110 is provided below with reference to FIG. 2, and one or more operations executable by the test bench management system 110, as well as related use cases, are provided below with reference to FIGS. 3 to 5.

[0051] Each of the plurality of nodes 120-1 to 120-N may include any other suitable components that can perform operations such as receiving, hosting, storing, introducing, processing, and / or providing one or more artifacts or components that make up a test bench.

[0052] For example, node 120-1 may include a device or apparatus (e.g., a personal computer, a server or server cluster, a workstation, etc.) that can be used for building, storing, executing, or simulating one or more computer-executable software applications, such as one or more virtual ECUs of a vehicle system, one or more emulated ECUs, and / or any other suitable software-based components (e.g., a vehicle model, a data communication module (DCM) model, a heating, ventilation, and air conditioning (HVAC) model, etc.). As another example, node 120-1 may include one or more hardware components, such as one or more fully developed physical ECUs, one or more partially developed physical ECUs, one or more vehicle hardware (e.g., a powertrain, an engine, etc.).

[0053] According to an embodiment, one or more of the plurality of nodes 120-1 to 120-N can include one or more interfaces, each of which can be configured to communicatively couple the associated node to the test bench management system 110. For example, one or more of the plurality of nodes can include a hardware interface, a software interface (e.g., a program interface, an application program interface (API), etc.).

[0054] According to an embodiment, at least some of the plurality of nodes 120-1 to 120-N can be located at a geographical location different from the test bench management system 110, different from the other parts of the plurality of nodes, and / or different from the using party 140.

[0055] The network 130 can include one or more wired and / or wireless networks configured to couple the plurality of nodes 120-1 to 120-N to the test bench management system 110. For example, the network 130 can include a cellular network (e.g., a fifth generation (5G) network, a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone line network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0056] According to an embodiment, network 130 may include a virtual network that includes one or more physical network components (e.g., Ethernet (registered trademark), WiFi module, telecommunications network hardware, etc.) in which one or more virtual network functions (e.g., a controller area network (CAN) bus, etc.) are implemented. Additionally or alternatively, network 130 may include at least one parameter network. According to an embodiment, network 130 may also be configured to couple test bench management system 110 (or one or more components included therein) to other components such as utilization party 140 and multiple test environments, one or more devices or apparatuses of a user (e.g., a tester, etc.).

[0057] Utilization party 140 may include one or more systems, devices, etc. that are configured to utilize one or more information or data provided by test bench management system 110. According to an embodiment, utilization party 140 may be able to receive one or more test benches (or related information or data) from test bench management system 110 and may include a test management system that can utilize one or more test benches when managing one or more tests (e.g., scheduling of tests, triggering of test execution, etc.).

[0058] Additionally or alternatively, the utilization party 140 may include at least one software-based test environment (e.g., Software-in-the-Loop (SIL) test environment, Virtual ECU (V-ECU) test environment, Model-in-the-Loop (MIL) test environment, Processor-in-the-Loop (PIL) test environment, etc.) and / or at least one hardware-based test environment (e.g., Hardware-in-the-Loop (HIL) test environment, etc.), and they may utilize one or more test benches provided by the test bench management system 110 when executing one or more tests. According to an embodiment, at least a portion of the nodes 120-1 to 120-N is associated with at least a portion of the test environment of the utilization party 140. For example, in the case of the utilization party 140 including a software-based test environment, the utilization party may host (be able to execute) or introduce software-based components or artifacts at a portion of the nodes 120-1 to 120-N where they are introduced. Alternatively or additionally, in the case of the utilization party 140 including a hardware-based test environment, the utilization party may be communicatively coupled (via wireless and / or wired connections) to a portion of the nodes 120-1 to 120-N associated with the hardware-based components or artifacts.

[0059] Furthermore, the utilization party 140 may include one or more storage media, such as a server or a server cluster, configured to perform operations such as storing and publishing one or more test benches (or information related thereto) provided by the test bench management system 110.

[0060] Next, refer to FIG. 2, which shows a block diagram of exemplary components of a test bench management system 200 according to one or more embodiments. The test bench management system 200 may correspond to the test bench management system 110 described above with reference to FIG. 1, and thus, the features described herein with reference to systems 110 and 200 may be applicable to each other unless otherwise explicitly stated.

[0061] As shown in FIG. 2, the test bench management system 200 can include at least one communication interface 210, at least one storage 220, and at least one processor 230. However, the test bench management system 200 can include more or fewer components than those shown, and / or the components included therein can be arranged in any manner different from that shown without departing from the technical scope of the present disclosure.

[0062] The communication interface 210 can include a component such as a transceiver (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables the test bench management system 200 (or one or more components included therein) to communicate with one or more components external to the test management system 200 via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. For example, the communication interface 210 can couple the test bench management system 200 (or one or more components included therein) to a plurality of nodes (e.g., nodes 120-1 to 120-N in FIG. 1, etc.), thereby enabling them to communicate and interoperate with each other. As another example, the communication interface 210 can enable the components of the test bench management system 200 to communicate with each other. For example, the communication interface 210 can couple the storage 220 to the processor 230, thereby enabling them to communicate and interoperate with each other.

[0063] According to an embodiment, the communication interface 210 may include a hardware-based interface such as a bus interface, an Ethernet (registered trademark) interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, a software interface, etc. According to an embodiment, the communication interface 210 may include at least one controller area network (CAN) bus configurable to communicatively couple components of the test bench management system 200 (e.g., the storage 220, the processor 230, etc.) to a plurality of nodes (e.g., nodes 120-1 to 120-N) and / or at least one using party (e.g., the using party 140). Additionally or alternatively, the communication interface 210 may include a software-based interface such as an application programming interface (API), a virtual network interface (e.g., a virtual CAN bus, etc.).

[0064] According to an embodiment, the communication interface 210 may be configured to receive information from one or more components external to the test bench management system 200 and provide it to the processor 230 for further processing and / or to the storage 220 for storage. For example, the communication interface 210 may read the real-time or near real-time status of a task, obtain logs associated with the task, monitor the health status of a virtual vehicle (further described below), and enable one or more interactions between the virtual vehicle and the test environment and one or more users.

[0065] At least one storage 220 can include one or more storage media suitable for storing data, information, and / or computer-readable / computer-executable instructions. According to an embodiment, the storage 220 can include a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions for use by the processor 230.

[0066] Additionally or alternatively, the storage 220, along with a corresponding drive, can include a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium.

[0067] According to an embodiment, the storage 220 can operate as a centralized library and can be configured to store information utilized by the processor 230 to facilitate the provisioning or utilization of test benches for cross-domain testing. For example, the storage 220 can be configured to store one or more test bench parameters or settings predefined or determined by one or more users, such as one or more test conditions, information on one or more required software components / hardware components. Further, the storage 220 can be configured to store one or more test artifacts, components, resource information, etc., that make up the test bench. Further, the storage 220 can store computer-readable instructions that, when executed by one or more processors (e.g., the processor 230), cause the one or more processors to perform one or more actions or operations described herein.

[0068] At least one processor 230 may include one or more processors programmed to perform functions or operations to facilitate cross - domain testing. For example, the processor 230 may be configured to perform one or more operations or one or more actions described herein by executing computer - readable instructions stored in a storage medium (such as storage 220).

[0069] According to an embodiment, the processor 230 may be configured to receive one or more signals (e.g., via a communication interface 210, etc.) that define one or more instructions for performing one or more operations. Further, the processor 230 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 230 may include a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field - programmable gate array (FPGA), an application - specific integrated circuit (ASIC), and / or another type of processing or computing component.

[0070] According to an embodiment, the processor 230 executes computer - executable instructions stored in at least one memory storage (e.g., storage 220), thereby being configured to perform one or more operations to facilitate the provisioning and / or utilization of one or more test benches.

[0071] Refer to FIG. 3, which shows a flowchart of an exemplary method 300 for facilitating the provisioning of a test bench for cross - domain testing according to one or more embodiments. One or more operations of method 300 may be performed by at least one processor (e.g., processor 230) of a test bench management system to facilitate the provisioning of a test bench for cross - domain testing for testing one or more software related to an in - vehicle system of a vehicle (e.g., one or more in - vehicle ECUs, etc.). It should be understood that the at least one processor may be configured to perform one or more operations of method 300 to update or re - configure one or more test benches in a manner similar to that described herein.

[0072] According to an embodiment, method 300 may be triggered in response to detecting a change (e.g., an update, etc.) in one or more software under test. Similarly, method 300 may be triggered in response to detecting a change in resources, such as detecting resources that may improve test performance or detecting a failure (or potential unavailability) of a hardware component.

[0073] Referring to FIG. 3, in operation S310, at least one processor of the test bench management system may be configured to obtain one or more test bench settings related to one or more software under test. The one or more test bench settings may include software resources and / or hardware resources utilized or reserved for the test bench (e.g., software - based / hardware - based ECUs, computing power, memory, operating system, etc.), information defining the test bench, test components / artifacts related to the test, relationships and connections between test artifacts, types of test environments related to the test, one or more test conditions, one or more test procedures, derivative vehicles, vehicle communication specifications, and / or any other suitable information.

[0074] According to an embodiment, at least one processor may be configured to obtain one or more test bench settings by receiving one or more inputs defining a test bench from one or more users, obtaining a component catalog including information on available test artifacts or test components, determining, based on the one or more inputs, one or more test artifacts associated with the user-defined test bench from among the available test artifacts, and constructing one or more test bench settings based on the determined one or more test artifacts.

[0075] In some implementations, at least one processor may obtain one or more test bench settings in real-time or near real-time based on one or more user inputs provided by one or more users. For example, at least one processor may receive one or more inputs defining a test bench from one or more user devices via a communication interface (e.g., communication interface 210) of a test bench management system and construct one or more test bench settings on-the-fly based thereon.

[0076] Additionally or alternatively, one or more test bench configurations can be pre - constructed or defined and stored in one or more storage media (e.g., the storage 220 of the test bench management system, an external storage server of the test bench management system, etc.). In some implementations, one or more test bench configurations can be predefined by a first user, and at least one processor can determine that the one or more test bench configurations may be suitable for a second user (e.g., based on a determination that the second user is associated with the first user, or a determination that the tests intended by the second user are associated with the tests intended by the first user). Thus, in operation S310, at least one processor can access one or more storage media (e.g., via a communication interface) and obtain one or more test bench configurations therefrom.

[0077] Referring further to FIG. 3, upon obtaining one or more test bench configurations, method 300 can proceed to operation S320, where at least one processor of the test bench management system can be configured to obtain information about a plurality of test artifacts related to one or more test bench settings. According to an embodiment, the plurality of test artifacts can include at least one software component (e.g., a virtualized ECU, a vehicle - related model, etc.), at least one hardware component (e.g., a physical ECU, etc.), or a combination thereof. The information about the plurality of test artifacts can include the availability of the test artifacts, the location where the test artifacts are introduced or deployed, the access links related to the test artifacts, and / or any other suitable information.

[0078] In some implementations, at least one processor may be configured to obtain information on a plurality of test artifacts in real time or near real time from one or more nodes (e.g., nodes 120-1 to 120-N) communicatively coupled to the test bench management system. Additionally or alternatively, information on a plurality of test artifacts can be obtained in advance by at least one processor and stored in one or more storage media. In that case, in operation S320, at least one processor can access (e.g., via a communication interface) one or more storage media and obtain information on a plurality of test artifacts therefrom.

[0079] Referring further to FIG. 3, upon obtaining information on a plurality of test artifacts, method 300 proceeds to operation S330, where at least one processor of the test bench management system may be configured to generate a test bench based on the information on the plurality of test artifacts and the obtained test bench settings.

[0080] For this purpose, at least one processor of the test bench management system can automatically and dynamically facilitate the provisioning of one or more test benches for testing (e.g., cross-domain testing) when needed.

[0081] Upon generating one or more test benches, at least one processor of the test bench management system may be configured to utilize the generated one or more test benches.

[0082] According to an embodiment, at least one processor can provide one or more test benches to a test management system for further processing. For example, the test management system can be configured to utilize one or more test benches to execute one or more tests (e.g., cross-domain tests). In this regard, in some implementations, it should be understood that the test bench management system can also be configured to perform one or more operations executable by the test management system described herein without departing from the technical scope of the present disclosure.

[0083] According to an embodiment, at least one processor of the test bench management system can be configured to store the generated one or more test benches in one or more storage media such as the storage of the test bench management system (e.g., storage 220), a storage server external to the test bench management system, or any other suitable type of storage device or repository.

[0084] Furthermore, at least one processor can be configured to continuously (or periodically) monitor the status of the stored / generated one or more test benches and perform appropriate operations for managing the one or more test benches. For example, at least one processor can continuously (or periodically) monitor the status (e.g., version, availability, etc.) of test artifacts related to the one or more test benches (e.g., by continuously or periodically requesting relevant information from one or more nodes via, e.g., API calls), and can automatically reset the one or more test benches when necessary (e.g., based on determining that a relevant test artifact has been updated or that the relevant test artifact(s) is no longer available).

[0085] According to an embodiment, at least one processor of the test bench management system may be configured to create a virtual vehicle model based on one or more generated test benches. The virtual vehicle model can define the end-to-end architecture of the physical vehicle intended by the user, and software components (e.g., virtual ECUs, emulated ECUs, vehicle models, etc.) and hardware components (e.g., hardware prototypes, physical ECUs, etc.) can be dispersed or arranged at geographically different locations and communicatively coupled to each other via a network. Hereinafter, with reference to FIG. 5, an example of the virtual vehicle model will be described.

[0086] By creating a virtual vehicle model, the user can introduce one or more software onto the virtual vehicle model and perform integration and testing on demand regardless of the user's geographical location and the components of the virtual vehicle model. In this way, the user can quickly and effectively ensure that the software does not cause regressions and operates as expected before introducing the software into a physical test vehicle and ultimately into the customer's vehicle.

[0087] Refer to FIG. 4, which shows a flowchart of an exemplary method 400 for creating a virtual vehicle model according to one or more embodiments. One or more operations of method 400 can be performed by at least one processor (e.g., processor 230) of the test bench management system of the present disclosure, but it should be understood that the one or more operations can also be performed by any other suitable component of any other suitable system for creating a virtual vehicle model without departing from the technical scope of the present disclosure. Further, one or more operations of method 400 may be performed after one or more operations of method 300 (described above with reference to FIG. 3).

[0088] As shown in FIG. 4, in operation S410, at least one processor of the test bench management system can be configured to introduce one or more software components associated with one or more test benches. According to an embodiment, at least one processor can determine, based on one or more test benches (e.g., test benches obtained or generated in the manner described above with reference to FIG. 3, etc.), which software components (e.g., virtual ECUs, emulated ECUs, etc.) are defined within the one or more test benches, and accordingly obtain and execute the software components. For example, the software components may be introduced into one or more containers, and at least one processor may obtain the one or more containers and execute instances of the one or more containers.

[0089] According to an embodiment, at least one processor can determine, based on one or more test benches, one or more resource requirements for introducing one or more software components, and can determine, from among a plurality of nodes or devices communicatively coupled to the test bench management system (e.g., nodes 120-1 to 120-N in FIG. 1, etc.), one or more nodes that satisfy the one or more resource requirements, and can introduce the one or more software components onto the determined one or more nodes.

[0090] As an example, at least one processor can determine a minimum computing power X and a minimum memory Y required for the execution of the container of the virtualized ECU from one or more test benches associated with the virtualized ECU. Accordingly, at least one processor can determine one or more nodes (e.g., user devices, equipment, processing servers, etc.) that can provide the minimum computing power X and the memory Y from among a plurality of nodes communicatively coupled to the test bench management system, and mount the container of the virtualized ECU on the determined one or more devices. In this way, at least one processor can dynamically introduce software components to any device that has available resources and meets the requirements defined in one or more test benches, regardless of the geographical location where the device is introduced.

[0091] Referring further to FIG. 4, in operation S420, at least one processor of the test bench management system can be configured to secure one or more hardware components associated with one or more test benches. According to an embodiment, at least one processor determines one or more hardware resource requirements (e.g., which hardware components (e.g., physical ECUs, etc.) are defined in one or more test benches) based on one or more test benches, and determines one or more hardware components (e.g., one or more hardware components that are available and meet the hardware requirements defined in one or more test benches) that meet the one or more hardware resource requirements from among a plurality of hardware components (e.g., nodes 120-1 to 120-N in FIG. 1, etc.) communicatively coupled to the test bench management system, and can secure the one or more hardware components.

[0092] As an example, at least one processor can determine from one or more test benches associated with the virtualized ECU that the virtualized ECU should interoperate with a physical ECU when executing a function. Accordingly, at least one processor can determine at least one physical ECU that meets the requirements from among a plurality of physical ECUs communicatively coupled to the test bench management system, and send a request to the physical ECU to secure the physical ECU. In this way, at least one processor can dynamically secure any physical ECU that meets the requirements defined by one or more test benches, regardless of the geographical location where the physical ECU is introduced.

[0093] It should be understood that at least one processor can execute operations S410 and S420 in any suitable sequence. For example, at least one processor can execute operations S410 and S420 in parallel without departing from the technical scope of the present disclosure, and can execute operation S420 before executing operation S410 and the like. In some implementations, the node into which the software component is introduced can have a software-based test environment (e.g., SIL test environment, etc.) introduced therein, the hardware component can be communicatively coupled to a hardware-based test environment (e.g., HIL test environment), and it should also be understood that the software-based test environment and the hardware-based test environment can provide signals or information that simulate the operation of the software / hardware component.

[0094] Referring further to FIG. 4, in operation S430, at least one processor of the test bench management system may be configured to create a virtual vehicle model. According to an embodiment, at least one processor may determine a relationship or connection between software components and hardware components based on one or more test benches, and then connect the software components to the hardware components based on the determined relationship, thereby creating a virtual vehicle model.

[0095] In some implementations, at least one processor may determine a vehicle communication specification that defines a relationship between software components and hardware components based on one or more test benches, generate network connection settings based on the vehicle communication specification, and provide the network connection settings to one or more networks (e.g., network 130), thereby connecting the software components and the hardware components. Accordingly, one or more networks may be configured to connect software components and hardware components when needed based on the network connection settings. In some embodiments, at least one processor may create a virtual network that defines a connection between software components and hardware components such that they communicate as if they were actual vehicles according to the communication specification of the derived vehicle.

[0096] Once the virtual model is created, at least one processor of the test bench management system may be configured to utilize the virtual model. For example, at least one processor may be configured to introduce one or more software under test into the virtual vehicle model (or provide the virtual model to the test management system) such that cross-domain testing can be performed. As another example, at least one processor may provide the virtual model to one or more storage media (e.g., storage 220, external server, etc.) for future use.

[0097] According to an embodiment, at least one processor of the test bench management system may be configured to generate a test rig based on a virtual vehicle model. In this regard, the test rig described herein may refer to one or more fixtures or components designated to systematically perform a specific test. In a cross-domain test, the test rig may refer to a specific test environment in which the cross-domain test is executed.

[0098] According to an embodiment, at least one processor of the test bench management system may be configured to generate a test rig by creating a virtual vehicle model (obtained in the same manner as described above with reference to FIG. 4) based on one or more test benches related to software (obtained in the same manner as described above with reference to FIG. 3), determining one or more test conditions based on the one or more test benches, and connecting the virtual vehicle model to the one or more test conditions.

[0099] The one or more test conditions may be defined by a user and may include traffic conditions, weather conditions, urban conditions, and any other suitable type of conditions intended by the user for testing the software. In some implementations, at least one processor may be further configured to generate the test rig in consideration of one or more test objectives (e.g., target test execution time, target test result, etc.) defined by the user. In this regard, it can be understood that parameters defined by the user, such as the one or more test conditions and / or the one or more test objectives, may be appropriately obtained by at least one processor (e.g., obtained from a user device in real time or near real time, obtained from one or more storage media, etc.).

[0100] Refer to FIG. 5, which shows a block diagram of an exemplary test rig 500 according to one or more embodiments. The test rig 500 can be generated by at least one processor of a test bench management system, as well as any other suitable system that can utilize one or more test benches provided by the test bench management system. In this exemplary use case, it is assumed that the test rig 500 is generated to perform cross-domain testing using an advanced driver assistance system (ADAS) ECU as the target software to be tested.

[0101] As shown in FIG. 5, the test rig 500 can include a virtual vehicle model 510 and a plurality of simulated conditions 520, but it should be understood that the test rig 500 can further include any other suitable components and / or can be arranged in a manner different from that shown in FIG. 5.

[0102] In this exemplary use case, the virtual vehicle model 510 includes a plurality of software components such as at least one central ECU (CECU), at least one instrument cluster (IC) ECU, at least one in-vehicle infotainment (IVI) ECU, and at least one ADAS ECU (i.e., the target software to be tested in this exemplary use case), and a plurality of hardware components such as at least one chassis ECU, at least one power train ECU, and at least one body ECU. The plurality of software components are communicably coupled to the plurality of hardware components via a virtual network, such that the plurality of software components can interact with each other in a similar manner as if they were communicating via a physical vehicle.

[0103] In other implementation forms, it should be understood that one or more of the central ECU, the IC ECU, and the IVI ECU can be physical and hardware-based, and / or one or more of the chassis ECU, the power train ECU, and the body ECU can be virtual and software-based. Further, it should also be understood that the virtual vehicle model 510 can include one or more additional components such as one or more vehicle models (e.g., DCM model, HVAC model, etc.), one or more vehicle parameters (e.g., derivative vehicle, etc.), or any other suitable components for simulating the virtual vehicle model to be more realistic with respect to the target vehicle.

[0104] Furthermore, in the exemplary use case of FIG. 5, it should be understood that the plurality of simulation conditions 520 include urban conditions, traffic conditions, and weather conditions, but the plurality of simulation conditions 520 can include any other suitable type of conditions as intended.

[0105] In view of the above, the test bench management system of the exemplary embodiment can automatically create one or more test rigs based on the test requirements and test conditions defined by the user, and then execute cross-domain tests for testing the target software based on the created test rigs.

[0106] Furthermore, the user can easily reconfigure the cross-domain test by, for example, providing a reconfigured version (e.g., updated version, different version, etc.) of the target software to the test bench management system, adding / removing one or more test conditions, etc., and the test bench management system can automatically update the test bench related to the target software, thereby updating the related test rigs in real time or near real time.

[0107] Furthermore, the test bench management system can continuously (or periodically) monitor the availability of software resources and hardware resources, and automatically reset the test rig based on a determination that the currently utilized software resources and / or hardware resources are no longer optimal. For example, based on a determination that a software component can be introduced and another device that can provide better performance (e.g., higher computing power, etc.) is available, the test bench management system can reintroduce the software component to the other device. As another example, based on a determination that a hardware component is no longer available (e.g., due to unexpected hardware problems, etc.) or that the hardware component will not be immediately available (e.g., due to reservations by other users, etc.), the test bench management system can search for one or more other available hardware components that meet the requirements defined in one or more test benches and secure the one or more other hardware components. In this way, the test bench management system can automatically reset the test rig based on real-time or near real-time resource conditions, thereby ensuring that cross-domain testing can be executed without interruption.

[0108] It should be understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an illustrative approach. Based on design preferences, it should be understood that the specific order or hierarchy of blocks in a process / flowchart can be reconfigured. Furthermore, some blocks can be combined or omitted. The appended method claims present the elements of the various blocks in an illustrative order and are not limited to the specific order or hierarchy presented.

[0109] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium having computer-readable program instructions for causing a processor to perform operations.

[0110] A computer readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. A computer readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage media includes the following: portable computer diskettes, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the above. Computer-readable media as used herein should not be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0111] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0112] The computer-readable program code / instructions for performing the operations may be in source code or object code, in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or object-oriented programming languages such as Smalltalk, C++, and procedural programming languages such as the "C" programming language or similar program languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer, and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions by personalizing the electronic circuit using the state information of the computer-readable program instructions to perform the aspect or operation.

[0113] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for realizing the functions / operations specified in the blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium having stored therein instructions that cause a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner to comprise a manufactured article that includes instructions for realizing the functions / operations specified in the blocks of the flowchart and / or block diagram.

[0114] The computer-readable program instructions can also be loaded onto a computer, other programmable apparatus, or other device, such that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce a process that is realized by the computer to realize the functions / operations specified in the blocks of the flowchart and / or block diagram.

[0115] The flowcharts and block diagrams in the drawings illustrate the structure, functions, and operations of possible realizations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram can represent a module, segment, or part of an instruction, and they include one or more executable instructions for implementing a specified logical function. The methods, computer systems, and computer-readable media can include additional blocks, fewer blocks, different blocks, or blocks arranged differently than those shown in FIG. 1. In some alternative realizations, the functions shown in the blocks can occur in a different order than shown in the figure. For example, two blocks shown consecutively can actually be executed simultaneously or substantially simultaneously, or depending on the functions involved, the blocks can be executed in the reverse order. It will also be noted that each block in the illustration of the block diagram and / or flowchart, and combinations of blocks in the illustration of the block diagram and / or flowchart, can be implemented by a system based on special-purpose hardware that performs the specified function or operation and a combination of special-purpose hardware and computer instructions.

[0116] The systems and / or methods described herein can be realized in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods does not limit the realizations. Therefore, the operations and behaviors of the systems and / or methods have been described herein without reference to specific software code, and it is understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. A method for managing a test bench for cross - domain testing of software of an embedded system, implemented by at least one processor of the system, comprising: obtaining test bench settings associated with the software; obtaining information on a plurality of test artifacts associated with the test bench settings; generating a test bench associated with the cross - domain testing based on the plurality of test artifacts; wherein the software of the embedded system includes an in - vehicle electronic control unit (ECU). A method.

2. The obtaining the test bench settings includes: receiving from a user one or more inputs defining the test bench; obtaining a component catalog including information on available test artifacts; determining, based on the one or more inputs, one or more test artifacts associated with the test bench defined by the user from among the available test artifacts; constructing test bench settings based on the determined one or more test artifacts. The method according to claim 1.

3. The plurality of test artifacts includes at least one software component, at least one hardware component, or a combination thereof. The method according to claim 1 or claim 2.

4. At least a part of the plurality of test artifacts is introduced at geographically different locations. The method according to claim 1 or claim 2.

5. The at least one software component includes at least one virtual ECU, at least one emulated ECU, or a vehicle - related model. The at least one hardware component includes at least one physical ECU. The method according to claim 3.

6. introducing the at least one software component based on the test bench; securing the at least one hardware component based on the test bench; creating a virtual vehicle model based on the at least one software component and the at least one hardware component. The method according to claim 3, further comprising

7. Introducing the at least one software component includes Determining, based on the test bench, at least one resource requirement for introducing the at least one software component; Determining at least one node from among a plurality of nodes communicatively coupled to the system that meets the at least one resource requirement; Introducing the at least one software component into the determined at least one node. The method according to claim 6, comprising

8. Securing the at least one hardware component includes Determining at least one hardware resource requirement based on the test bench; Determining the at least one hardware component from among a plurality of hardware components communicatively coupled to the system that meets the at least one hardware resource requirement; Securing the at least one hardware component. The method according to claim 6, comprising

9. Creating the virtual vehicle model includes Determining a relationship between at least one software component and at least one hardware component based on the test bench; Connecting at least one software component to at least one hardware component based on the determined relationship. The method according to claim 6, comprising

10. The method according to claim 6, further comprising generating a test rig for the cross-domain test based on the virtual vehicle model. The method according to claim 6.

11. A system for managing a test bench for cross-domain testing of software in an embedded system, comprising At least one memory storage storing computer-executable instructions; Communicatively coupled to the at least one memory storage and Obtaining test bench settings associated with the software, Obtaining information on a plurality of test artifacts associated with the test bench settings, Generating a test bench associated with the cross-domain test based on the plurality of test artifacts. At least one processor configured to execute the computer-executable instructions for; including; wherein the software of the embedded system includes an in-vehicle electronic control unit (ECU); system.

12. The at least one processor; receives one or more inputs defining a test bench from a user, obtains a component catalog containing information on available test artifacts, determines, based on the one or more inputs, one or more test artifacts associated with the test bench defined by the user from among the available test artifacts, constructs a test bench configuration based on the determined one or more test artifacts; thereby being configured to execute the computer-executable instructions for obtaining the test bench configuration; The system according to claim 11.

13. The plurality of test artifacts includes at least one software component, at least one hardware component, or a combination thereof; The system according to claim 11 or claim 12.

14. At least a portion of the plurality of test artifacts is introduced at geographically different locations; The system according to claim 11 or claim 12.

15. The at least one software component includes at least one virtual ECU, at least one emulated ECU, or a vehicle-related model; The at least one hardware component includes at least one physical ECU; The system according to claim 13.

16. The at least one processor; introduces the at least one software component based on the test bench, secures the at least one hardware component based on the test bench, creates a virtual vehicle model based on the at least one software component and the at least one hardware component; thereby being configured to execute the computer-executable instructions for; The system according to claim 13.

17. The at least one processor; Determine at least one resource requirement for introducing the at least one software component based on the test bench, Determine at least one node that meets the at least one resource requirement from among a plurality of nodes communicatively coupled to the system, Introduce at least one software component into the determined at least one node, Thereby being configured to execute the computer-executable instructions for introducing the at least one software component, The system according to claim 16.

18. The at least one processor, Determine at least one hardware resource requirement based on the test bench, Determine the at least one hardware component that meets the at least one hardware resource requirement from among a plurality of hardware components communicatively coupled to the system, Secure the at least one hardware component, Thereby being configured to execute the computer-executable instructions for securing the at least one hardware component, The system according to claim 16.

19. The at least one processor, Determine the relationship between at least one software component and at least one hardware component based on the test bench, Connect at least one software component to at least one hardware component based on the determined relationship, Thereby being configured to execute the computer-executable instructions for creating the virtual vehicle model, The system according to claim 16.

20. The at least one processor, Is further configured to execute the computer-executable instructions for generating a test rig for the cross-domain test based on the virtual vehicle model, The system according to claim 16.

Images