SYSTEM AND METHOD FOR MANAGING TEST BENCHES FOR CROSS-DOMAIN TESTING

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 example 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 technology]

[0002] In software testing, a testbench may refer to a set of tools, procedures, functional configurations, equipment, and other information or parameters that, when compiled or utilized, enable tests to be executed in desired conditions, environments, or settings.

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

[0004] Resources used in a test bench for software testing may 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, hardware resources may include one or more physical electronic control units (ECUs) with which a target ECU (e.g., an ECU under test) interacts, one or more servers on which relevant data or information is hosted, and / or the like. In addition to hardware resources, a test bench for software testing may also include requirements on software resources. For example, in a vehicle embedded system, software resources may include one or more virtualized or emulated ECUs with which a target ECU interacts, one or more operating systems for running tests, and / or the like.

[0005] In simple terms, the relationship between test benches and resources in software testing is that a test bench provides or defines the resources required to run tests and evaluate the performance of software under various conditions. By simulating the actual environment or conditions in which the software will be deployed, a test bench helps to identify and address any issues or defects in the software, verify the correctness of the software's design soundness, etc. before the software is deployed in the actual production environment. This helps to ensure that the software is reliable, performs well, and meets its requirements.

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

[0007] In view of the above, test benches are required to be carefully configured and designed to ensure efficient and effective testing. Nevertheless, as described below, the provision and availability of test benches for testing relevant vehicle-related software is limited, inefficient, and ineffective.

[0008] First, in the prior art, whenever testing of a software component involves a specific hardware component (e.g., a specific physical ECU), a user is required to visit a specific test facility where the specific hardware component is installed, couple the software component to the hardware component, configure the test bench accordingly, and then run the test. Therefore, accessing and using the test bench is time-consuming because the user must physically travel to the specific test facility before being able to access the test bench.

[0009] Furthermore, the hardware deployed in test facilities is limited and restricted to specific types or variants, reducing the number of parallel tests possible, making it difficult to build or configure test benches on-site, and test benches built for a specific vehicle variant cannot be used for other vehicle variants.

[0010] For example, because the hardware resources of a test facility are physically fixed and deployed in a black-box manner whenever a test is in progress (e.g., a user using the test facility can reserve most, if not all, of the resources in the test facility), it is excessively difficult (if not impossible) for multiple users to use the test facility simultaneously, and it is difficult (if not impossible) for a user to run multiple tests at the test facility simultaneously. Therefore, whenever a user has multiple tests to run and / or multiple users want to use the test facility, job collision issues may arise, and users must take turns (e.g., by making reservations on a waiting list). However, this significantly slows down testing and ultimately the development of software (e.g., ECUs). Furthermore, the allocation and coordination between users and tests is managed manually, which is inefficient and burdensome for users.

[0011] Furthermore, whenever a specific software component (e.g., a specific type of virtual ECU, a specific operating system, etc.) is required but is not available at the test facility, the user must make a request to the test facility manager to obtain the specific software component, and the manager must search for and then obtain the requested software component. This not only causes further delays in software testing, but also incurs additional costs (human resources, fees charged to obtain the required software component, etc.).

[0012] Furthermore, test benches are typically installed and provided in test facilities and are often predefined and generic. Therefore, users may need to frequently configure the test bench to accommodate intended test requirements. Nevertheless, in the prior art, users must manually configure the provided test bench, which is time-consuming and may require the user to have a good technical understanding of the system to properly configure the test bench. In this regard, users who do not have a good understanding or experience in configuring the test bench may not be able to configure the test bench efficiently and accurately, which may result in inaccurate testing and human error.

[0013] Test bench provisioning and utilization becomes more challenging and complex when cross-domain testing is involved, which is required when developing advanced or complex features of vehicle systems (e.g., lane change assist, mobile smart key, etc.). This is because cross-domain testing involves testing multiple software and hardware components across multiple systems, resulting in a significant number of components, users / stakeholders, test requirements, etc., which increases the dynamic nature of the test bench setup and the resources required to perform cross-domain testing.

[0014] In conventional techniques, it is excessively difficult to appropriately and dynamically provide a testbench for reserving resources for cross-domain testing. Instead, considerable time is required to collect necessary information and configure necessary software and hardware components before configuring the testbench. Therefore, it takes time to prepare and execute cross-domain testing. Furthermore, every time a change occurs during cross-domain testing (e.g., a software update during testing, a hardware component failure, etc.), the testbench must be redesigned or reconfigured, which may further delay testing and ultimately software development. Furthermore, resources reserved for cross-domain testing may be over-provisioned (which may result in resource waste) or under-provisioned (which may result in inefficient test execution and further delays in software development) because resource requirements are dynamic and may change continuously (or occasionally).

[0015] In view of the above, prior art approaches to provisioning and utilizing test benches for cross-domain testing are limited, inefficient, and burdensome to users, which can ultimately lengthen the lead time from system-on-chip (SoC) specification to vehicle start of production (SOP). Summary of the Invention

[0016] According to embodiments, methods, systems, and devices are provided for automatically managing one or more test benches for cross-domain testing to test one or more software components of a system. Specifically, the methods, systems, devices, etc. of the exemplary embodiments can automatically obtain 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 configuration associated with the software, obtaining information of a plurality of test artifacts associated with the test bench configuration, and generating a test bench associated with the cross-domain testing based on the plurality of test artifacts.

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

[0019] According to an embodiment, the software of the embedded system may include an on-board electronic control unit (ECU). 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. Furthermore, at least some of the plurality of test artifacts may be deployed in different geographical locations.

[0020] According to an embodiment, the method may further include: deploying at least one software component based on the 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, deploying at least one software component may include determining at least one resource requirement for deploying the at least one software component based on a test bench, determining at least one node from among a plurality of nodes communicatively coupled to the system that satisfies the at least one resource requirement, and deploying the at least one software component to the determined at least one node.

[0022] According to an embodiment, reserving 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 from among a plurality of hardware components communicatively coupled to the system that satisfies the at least one hardware resource requirement, and reserving the at least one hardware component.

[0023] According to an embodiment, creating the 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 that stores computer-executable instructions, and at least one processor communicatively coupled to the at least one memory storage and configured to execute the computer-executable instructions to: obtain a test bench configuration associated with the software, obtain information of a plurality of test artifacts associated with the test bench configuration, and generate a test bench associated with the cross-domain testing based on the plurality of test artifacts.

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

[0026] According to an embodiment, the software of the embedded system may include an on-board electronic control unit (ECU). 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. Furthermore, at least some of the plurality of test artifacts may be deployed in different geographical locations.

[0027] According to an embodiment, the at least one processor may be configured to execute computer-executable instructions for: deploying at least one software component based on the 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. The at least one processor may also be 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 deploying at least one software component by determining, based on the test bench, at least one resource requirement for deploying at least one software component, determining, from among a plurality of nodes communicatively coupled to the system, at least one node that satisfies the at least one resource requirement, and deploying the at least one software component to the determined at least one node.

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

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

[0031] Additional aspects will be set forth in part in the description that follows, and in part will be obvious from the description, or may be realized by practice of the presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0032] The features, advantages, and benefits of exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like numerals refer to like elements and in which:

[0033] [Figure 1] FIG. 1 is a block diagram of an exemplary system configuration for managing test benches for cross-domain testing, according to one or more embodiments.

[0034] [Figure 2] FIG. 2 is a block diagram of example components of a test bench management system according to one or more embodiments.

[0035] [Figure 3] FIG. 3 is a flow diagram of an example method for facilitating provisioning of a test bench for cross-domain testing, according to one or more embodiments.

[0036] [Figure 4] FIG. 4 is a flow diagram of an exemplary method for creating a virtual vehicle model, according to one or more embodiments.

[0037] [Figure 5]FIG. 5 is a block diagram of an exemplary test rig, according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[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 implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired by practice of the implementations. Furthermore, one or more features or components of one or more embodiments may be incorporated into or combined with other embodiments (or one or more features of other embodiments). Additionally, in the descriptions of 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 concurrently (at least in part), and the order of one or more operations may be switched.

[0039] Although particular combinations of features are recited in the claims and / or disclosed herein, such combinations are not intended to limit the disclosure of possible implementations. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0040] No element, operation, or instruction used herein should be construed as critical or essential unless expressly stated as such. Also, as used herein, 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 "a" or similar language is used. Also, as used herein, terms such as "have," "having," "include," "including," and the like are intended to be open-ended and unrestricted. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases 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 illustrated embodiment is included in at least one embodiment of the solution. Thus, the phrases "in one embodiment," "in an embodiment," "a non-limiting preferred embodiment," and similar terms throughout this specification may, but do not necessarily, all refer to the same embodiment.

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

[0043] Example embodiments consistent with the present disclosure provide methods, systems, and apparatus for facilitating the provisioning and / or utilization of at least one test bench for cross-domain testing for testing one or more software of an embedded system, such as one or more on-board 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 configurations and automatically generate one or more test benches based thereon. The one or more test bench configurations can be associated with one or more user inputs that define the intended test bench, such as software and / or hardware components required to test a particular software.

[0045] The generated one or more test benches may 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 may 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 may be generated based on the virtual vehicle model and the generated one or more test benches, and the one or more test rigs may be provided or utilized for cross-domain testing.

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

[0047] To this end, a user can remotely configure one or more conditions to define requirements for performing cross-domain testing, and the necessary test benches can be automatically and appropriately provided and configured in real time or near real time, without the user needing to physically visit a test facility. Ultimately, exemplary embodiments of the present disclosure enable software development to be more efficient, significantly reducing the burden on users, significantly reducing development time, and significantly reducing the cost and effort of planning visits and travel to test facilities.

[0048] The features, advantages, and significance of the above exemplary embodiments are intended to be only a part of the present disclosure and are not intended to be exhaustive 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, as well as the technical advantages and significance thereof, are provided below.

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

[0050] In general, test bench management system 110 may be communicatively coupled to a plurality of nodes 120-1 through 120-N (via network 130) and utilising party 140, and configured to interoperate with the plurality of nodes 120-1 through 120-N and provide test benches (or one or more related information or data) to utilising party 140. A description of example components that may be included in test bench management system 110 is provided below with reference to FIG. 2, and one or more operations performable by test bench management system 110, as well as associated use cases, are provided below with reference to FIGS. 3 through 5.

[0051] Each of the plurality of nodes 120-1 to 120-N may include any other suitable component that may receive, host, store, deploy, process, and / or provide one or more artifacts or components that constitute the test bench.

[0052] For example, node 120-1 may include a device or equipment (e.g., a personal computer, a server or server cluster, a workstation, etc.) that may be utilized to build, store, execute, or simulate one or more computer-executable software applications, such as one or more virtual ECUs, one or more emulated ECUs, and / or any other suitable software-based components of a vehicle system (e.g., a vehicle model, a data communications 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 through 120-N may include one or more interfaces, each of which may be configured to communicatively couple the associated node to test bench management system 110. For example, one or more of the plurality of nodes may include a hardware interface, a software interface (e.g., a program interface, an application program interface (API), etc.), etc.

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

[0055] Network 130 may include one or more wired and / or wireless networks that may be configured to couple multiple nodes 120-1 through 120-N to test bench management system 110. For example, network 130 may 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 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 may include one or more physical network components (e.g., Ethernet, WiFi modules, telecommunications network hardware, etc.) on which one or more virtual network functions (e.g., 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 utilizing party 140, multiple test environments, one or more devices or equipment of a user (e.g., testers, etc.), etc.

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

[0058] Additionally or alternatively, Utilizing Party 140 may include at least one software-based test environment (e.g., a Software-in-the-Loop (SIL) test environment, a Virtual ECU (V-ECU) test environment, a Model-in-the-Loop (MIL) test environment, a Processor-in-the-Loop (PIL) test environment, etc.) and / or at least one hardware-based test environment (e.g., a Hardware-in-the-Loop (HIL) test environment, etc.), which may utilize one or more test benches provided by Test Bench Management System 110 in executing one or more tests. According to an embodiment, at least a portion of Nodes 120-1 through 120-N are associated with at least a portion of the test environments of Utilizing Party 140. For example, in the case of Utilizing Party 140 including a software-based test environment, the Utilizing Party may be hosted (executably) or deployed on a portion of Nodes 120-1 through 120-N where software-based components or artifacts are deployed. Alternatively or additionally, in the case of a using party 140 that includes a hardware-based test environment, the using party may be communicatively coupled (via wireless and / or wired connections) to a portion of nodes 120-1 to 120-N associated with the hardware-based component or artifact.

[0059] Additionally, the using party 140 may also include one or more storage media, such as a server or server cluster, that may be configured to store, publish, etc., one or more test benches (or information related thereto) provided by the test bench management system 110.

[0060] Reference is now made to Figure 2, which illustrates a block diagram of exemplary components of a test bench management system 200 according to one or more embodiments. Test bench management system 200 may correspond to test bench management system 110 described above with reference to Figure 1, and thus features described herein with reference to systems 110 and 200 may be applicable to one another unless expressly stated otherwise.

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

[0062] Communications interface 210 may include transceiver-like components (e.g., a transceiver, a separate receiver and transmitter, etc.) that enable test bench management system 200 (or one or more components included therein) to communicate with one or more components external to test bench management system 200 via wired connections, wireless connections, a combination of wired and wireless connections, etc. For example, communications interface 210 may couple test bench management system 200 (or one or more components included therein) to multiple nodes (e.g., nodes 120-1 through 120-N in FIG. 1 ), thereby enabling them to communicate and interoperate with each other. As another example, communications interface 210 may enable components of test bench management system 200 to communicate with each other. For example, communications interface 210 may couple storage 220 to processor 230, thereby enabling them to communicate and interoperate with each other.

[0063] According to an embodiment, communication interface 210 may include a hardware-based interface, such as a bus interface, an Ethernet 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, communication interface 210 may include at least one controller area network (CAN) bus configurable to communicatively couple components of test bench management system 200 (e.g., storage 220, processor 230, etc.) to multiple nodes (e.g., nodes 120-1 through 120-N) and / or at least one using party (e.g., using party 140). Additionally or alternatively, 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.), etc.

[0064] According to an embodiment, communications interface 210 may be configured to receive information from one or more components external to test bench management system 200 and provide it to processor 230 for further processing and / or to storage 220 for storage. For example, communications interface 210 may read real-time or near real-time status of tasks, retrieve logs associated with tasks, monitor the health status of the virtual vehicle (described further 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 may include one or more storage media suitable for storing data, information, and / or computer-readable / computer-executable instructions. According to an embodiment, storage 220 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 230.

[0066] Additionally or alternatively, storage 220 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact disks (CDs), digital versatile disks (DVDs), floppy disks, cartridges, magnetic tape, and / or another type of non-transitory computer-readable medium, along with corresponding drives.

[0067] According to an embodiment, storage 220 can operate as a centralized library and can be configured to store information utilized by processor 230 to facilitate the provisioning or utilization of test benches for cross-domain testing. For example, 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 / hardware components, etc. Additionally, storage 220 can be configured to store one or more test artifacts, components, resource information, etc. that constitute a test bench. Additionally, storage 220 can store computer-readable instructions that, when executed by one or more processors (e.g., 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 that may be programmed to perform functions or operations to facilitate provisioning of cross-domain tests. For example, processor 230 may be configured to perform one or more acts or operations described herein by executing computer-readable instructions stored on a storage medium (e.g., storage 220, etc.).

[0069] According to an embodiment, processor 230 may be configured to receive one or more signals (e.g., via communications interface 210, etc.) that define one or more instructions for performing one or more operations. Furthermore, processor 230 may be implemented in hardware, firmware, or a combination of hardware and software. 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, processor 230 may be configured to execute computer-executable instructions stored in at least one memory storage (e.g., storage 220) to thereby perform one or more operations to facilitate provisioning and / or utilization of one or more test benches.

[0071] 3 , which illustrates a flow diagram of an example method 300 for facilitating 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 provisioning of a test bench for cross-domain testing for testing one or more software associated with an embedded system of a vehicle (e.g., one or more on-board ECUs, etc.). It should be understood that the at least one processor may be configured to perform one or more operations of method 300 for updating or reconfiguring one or more test benches in a manner similar to that described herein.

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

[0073] 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 associated with one or more software under test. The one or more test bench settings may include software and / or hardware resources (e.g., software-based / hardware-based ECUs, computing power, memory, operating systems, etc.) utilized or reserved for the test bench, information defining the test bench, test components / artifacts associated with the test, relationships and connections between the test artifacts, a type of test environment associated with the test, one or more test conditions, one or more test procedures, a derived vehicle, 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 configurations by receiving one or more inputs from one or more users defining a test bench, obtaining a component catalog including information of available test artifacts or test components, determining one or more test artifacts from among the available test artifacts based on the one or more inputs to be associated with the user-defined test bench, and constructing one or more test bench configurations based on the determined one or more test artifacts.

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

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

[0077] 3 , upon obtaining one or more test bench configurations, method 300 may proceed to operation S320, where at least one processor of the test bench management system may be configured to obtain information of a plurality of test artifacts associated with the one or more test bench configurations. According to an embodiment, the plurality of test artifacts may 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 of the plurality of test artifacts may include availability of the test artifacts, locations where the test artifacts are installed or located, access links associated with the test artifacts, and / or any other suitable information.

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

[0079] Continuing with reference to FIG. 3 , upon obtaining the information of the plurality of test artifacts, method 300 may proceed 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 of the plurality of test artifacts and the obtained test bench settings.

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

[0081] Upon generating the 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 embodiments, the at least one processor may provide one or more test benches to a test management system for further processing. For example, the test management system may be configured to utilize the one or more test benches to execute one or more tests (e.g., cross-domain tests). In this regard, it should be understood that in some implementations, the test bench management system may also be configured to perform one or more operations executable by the test management system described herein without departing from the scope of the present disclosure.

[0083] According to an embodiment, at least one processor of the test bench management system may be configured to store the generated one or more test benches in one or more storage media, such as 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] Additionally, the at least one processor may be configured to continuously (or periodically) monitor the status of one or more stored / generated test benches and perform appropriate operations to manage the one or more test benches. For example, the at least one processor may continuously (or periodically) monitor the status (e.g., version, availability, etc.) of test artifacts associated with the one or more test benches (e.g., by continuously or periodically requesting relevant information from one or more nodes via API calls, etc.), and may automatically reconfigure the one or more test benches when necessary (e.g., based on determining that an associated test artifact has been updated, determining that one or more associated test artifacts are no longer available, etc.).

[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 the generated test bench or test benches. The virtual vehicle model may define the end-to-end architecture of a user-intended physical vehicle, and software components (e.g., virtual ECUs, emulated ECUs, vehicle models, etc.) and hardware components (e.g., hardware prototypes, physical ECUs, etc.) may be distributed or located in different geographic locations and communicatively coupled to each other via a network. An example of a virtual vehicle model is described below with reference to FIG. 5.

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

[0087] Reference is now made to FIG. 4, which illustrates a flow diagram of an exemplary method 400 for creating a virtual vehicle model, according to one or more embodiments. While one or more operations of method 400 may be performed by at least one processor (e.g., processor 230) of the test bench management system of the present disclosure, it should be understood that the one or more operations may also be performed by any other suitable component of any other suitable system in creating a virtual vehicle model without departing from the scope of the present disclosure. Furthermore, 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] 4, in operation S410, at least one processor of the test bench management system may be configured to deploy one or more software components associated with one or more test benches. According to an embodiment, the at least one processor may 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 retrieve and execute the software components accordingly. For example, the software components may be deployed within one or more containers, and the at least one processor may retrieve 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 one or more resource requirements for deploying one or more software components based on one or more test benches, can determine one or more nodes that satisfy the one or more resource requirements from among a plurality of nodes or devices (e.g., nodes 120-1 to 120-N in FIG. 1 ) communicatively coupled to the test bench management system, and can deploy one or more software components on the determined one or more nodes.

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

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

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

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

[0094] 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, the at least one processor may determine relationships or connections between software components and hardware components based on the one or more test benches, and then connect the software components to the hardware components based on the determined relationships, thereby creating the virtual vehicle model.

[0095] In some implementations, the at least one processor may connect the software components and the hardware components by determining, based on one or more test benches, vehicle communication specifications that define relationships between the software components and the hardware components, generating network connection settings based on the vehicle communication specifications, and providing the network connection settings to one or more networks (e.g., network 130). Thus, the one or more networks may be configured to connect the software components and the hardware components when needed based on the network connection settings. In some embodiments, the at least one processor may create virtual networks that define connections between the software components and the hardware components according to the communication specifications of the derived vehicles as if communicating between actual vehicles.

[0096] Upon creating the virtual model, at least one processor of the test bench management system may be configured to utilize the virtual model. For example, the at least one processor may be configured to deploy one or more pieces of software under test into the virtual vehicle model (or provide the virtual model to the test management system) so that cross-domain testing can be performed. As another example, the at least one processor may provide the virtual model to one or more storage media (e.g., storage 220, an external server, etc.) to store the virtual model 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 the virtual vehicle model. In this regard, a test rig as described herein may refer to one or more fixtures or components designated to systematically perform a particular test. In cross-domain testing, a test rig may refer to a particular test environment in which the cross-domain test is performed.

[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 a manner similar to that described above with reference to FIG. 4) based on one or more test benches associated with the software (obtained in a manner similar to that 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 types of conditions intended by the user for testing the software. In some implementations, the at least one processor may be further configured to generate the test rig taking into account one or more test goals defined by the user (e.g., target test execution time, target test results, etc.). In this regard, it may be understood that user-defined parameters, such as the one or more test conditions and / or the one or more test goals, may be suitably obtained by the 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] 5, which illustrates a block diagram of an exemplary test rig 500, according to one or more embodiments. Test rig 500 may be generated by at least one processor of a test bench management system, as well as any other suitable system that may utilize one or more test benches provided by the test bench management system. In this exemplary use case, test rig 500 has been 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 , test rig 500 may include virtual vehicle model 510 and multiple simulated conditions 520, although it should be understood that test rig 500 may further include any other suitable components and / or may be arranged in a manner different from that shown in FIG. 5 .

[0102] In this exemplary use case, the virtual vehicle model 510 includes multiple 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 multiple hardware components, such as at least one chassis ECU, at least one powertrain ECU, and at least one body ECU. The multiple software components are communicatively coupled to the multiple hardware components via a virtual network, such that the multiple software components can interoperate with each other in a similar manner as if they were communicating via a physical vehicle.

[0103] It should be understood that in other implementations, one or more of the central ECU, IC ECU, and IVI ECU may be physical and hardware-based, and / or one or more of the chassis ECU, powertrain ECU, and body ECU may be virtual and software-based. It should also be understood that the virtual vehicle model 510 may 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., vehicle derivatives, etc.), or any other suitable components for further simulating the virtual vehicle model to be more realistic with respect to the target vehicle.

[0104] Further, in the example use case of FIG. 5, the plurality of simulated conditions 520 includes urban conditions, traffic conditions, and weather conditions, however, it should be understood that the plurality of simulated conditions 520 may include any other suitable types of conditions as intended.

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

[0106] Furthermore, a user can easily reconfigure cross-domain tests, for example, by providing a reconfigured version (e.g., an updated version, a 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 associated with the target software, thereby updating the associated test rig in real time or near real time.

[0107] Furthermore, the test bench management system can continuously (or periodically) monitor the availability of software and hardware resources and automatically reconfigure the test rig based on a determination that the currently utilized software and / or hardware resources are no longer optimal. For example, based on determining that another device is available into which a software component can be deployed and that can provide better performance (e.g., higher computing power), the test bench management system can redeploy the software component to the other device. As another example, based on determining that a hardware component is no longer available (e.g., due to an unexpected hardware problem) or is not immediately available (e.g., due to reservation by another user), the test bench management system can search for and secure another available hardware component(s) that meets the requirements defined in the test bench(es). In this way, the test bench management system can automatically reconfigure the test rig based on real-time or near-real-time resource conditions, thereby ensuring uninterrupted execution of cross-domain tests.

[0108] It should be understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an example approach. Based on design preferences, it should be understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Additionally, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in an example 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 memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), 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 over wires.

[0111] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or can be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, 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 forwards 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 operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or object-oriented programming languages ​​such as Smalltalk, C++, etc., and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a standalone software package, and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information in the computer-readable program instructions to personalize the electronic circuitry to perform aspects or operations.

[0113] These computer-readable program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to fabricate a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram blocks. These computer-readable program instructions can also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having stored thereon instructions comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0114] The computer-readable program instructions can also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process such that the instructions, executed on the computer, other programmable apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram blocks.

[0115] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction set, comprising one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than shown in FIG. 1. In some alternative implementations, the functions depicted in the blocks may occur out of the order depicted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It will also be noted that each block in the block diagram and / or flowchart illustrations, and combinations of blocks in the block diagram and / or flowchart illustrations, may be implemented by special-purpose hardware-based systems that perform the specified functions or operations and execute a combination of special-purpose hardware and computer instructions.

[0116] The systems and / or methods described herein may be implemented 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 is not intended to limit the implementation. As such, the operation and behavior of the systems and / or methods have been described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method for managing a test bench for cross-domain testing of software of an embedded system, the test bench being implemented by at least one processor of the system, the method comprising: obtaining a test bench configuration associated with the software; obtaining information about a plurality of test artifacts associated with the test bench configuration; generating a test bench associated with the cross-domain test based on the plurality of test artifacts; Including, the software of the embedded system includes an on-board electronic control unit (ECU); the plurality of test artifacts include at least one software component, at least one hardware component, or a combination thereof; The method comprises: deploying 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; further comprising Deploying the at least one software component comprises: determining at least one resource requirement for deploying the at least one software component based on the test bench; determining at least one node from among a plurality of nodes communicatively coupled to the system that satisfies the at least one resource requirement; deploying at least one software component to the determined at least one node; A method comprising:

2. 1. A method for managing a test bench for cross-domain testing of software of an embedded system, the test bench being implemented by at least one processor of the system, the method comprising: obtaining a test bench configuration associated with the software; obtaining information about a plurality of test artifacts associated with the test bench configuration; generating a test bench associated with the cross-domain test based on the plurality of test artifacts; Including, the software of the embedded system includes an on-board electronic control unit (ECU); the plurality of test artifacts include at least one software component, at least one hardware component, or a combination thereof; The method comprises: deploying 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; further comprising Securing the at least one hardware component comprises: determining at least one hardware resource requirement based on the test bench; determining, from among a plurality of hardware components communicatively coupled to the system, the at least one hardware component that satisfies the at least one hardware resource requirement; securing said at least one hardware component; A method comprising:

3. obtaining the test bench configuration, receiving one or more inputs from a user defining a testbench; Obtaining a component catalog containing information about available test artifacts; determining, based on one or more inputs, from among the available test artifacts, one or more test artifacts associated with the user-defined test bench; constructing a testbench configuration based on the determined one or more test artifacts; 3. The method of claim 1 or claim 2, comprising:

4. at least some of the plurality of test artifacts are deployed at different geographic 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 1 or claim 2.

6. Creating the virtual vehicle model comprises: 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; 3. The method of claim 1 or claim 2, comprising:

7. generating a test rig for the cross-domain testing based on the virtual vehicle model. The method according to claim 1 or claim 2.

8. A system for managing a test bench for cross-domain testing of software for an embedded system, comprising: at least one memory storage device storing computer-executable instructions; communicatively coupled to the at least one memory storage; obtaining a test bench configuration associated with the software; obtaining information about a plurality of test artifacts associated with the test bench configuration; 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, the software of the embedded system includes an on-board electronic control unit (ECU); the plurality of test artifacts include at least one software component, at least one hardware component, or a combination thereof; The at least one processor deploying 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; configured to execute the computer-executable instructions for The at least one processor determining at least one resource requirement for deploying the at least one software component based on the test bench; determining at least one node from among a plurality of nodes communicatively coupled to the system that satisfies the at least one resource requirement; deploying at least one software component to the determined at least one node; a system configured to execute the computer-executable instructions for deploying the at least one software component by:

9. A system for managing a test bench for cross-domain testing of software for an embedded system, comprising: at least one memory storage device storing computer-executable instructions; communicatively coupled to the at least one memory storage; obtaining a test bench configuration associated with the software; obtaining information about a plurality of test artifacts associated with the test bench configuration; 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, the software of the embedded system includes an on-board electronic control unit (ECU); the plurality of test artifacts include at least one software component, at least one hardware component, or a combination thereof; The at least one processor deploying 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; configured to execute the computer-executable instructions for The at least one processor determining at least one hardware resource requirement based on the test bench; determining, from among a plurality of hardware components communicatively coupled to the system, the at least one hardware component that satisfies the at least one hardware resource requirement; securing said at least one hardware component; a system configured to execute the computer-executable instructions to secure the at least one hardware component by:

10. The at least one processor receiving one or more inputs from a user defining a test bench; Retrieves a component catalog containing information about available test artifacts, determining, based on one or more inputs, from among the available test artifacts, one or more test artifacts associated with the user-defined test bench; constructing a test bench configuration based on the determined one or more test artifacts; configured to execute the computer-executable instructions for obtaining the test bench configuration by 10. The system according to claim 8 or claim 9.

11. at least some of the plurality of test artifacts are deployed at different geographic locations; 10. The system according to claim 8 or claim 9.

12. 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.

10. The system according to claim 8 or claim 9.

13. The at least one processor 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; configured to execute the computer-executable instructions to create the virtual vehicle model by 10. The system according to claim 8 or claim 9.

14. The at least one processor and further configured to execute the computer-executable instructions to generate a test rig for the cross-domain testing based on the virtual vehicle model.

10. The system according to claim 8 or claim 9.

Images