System and method for managing test platform for cross-domain testing

Abstract

The invention relates to a system and method for managing a test platform for cross-domain testing. The present disclosure provides systems, methods, and apparatus for facilitating pre-configuration and / or utilization of a test platform for cross-domain testing that tests software of an embedded system. According to an embodiment, a method may be implemented by at least one processor, the method may include: obtaining a test platform setting associated with software; acquiring information of a plurality of test workpieces associated with the test platform settings; and generating a test platform associated with the cross-domain test based on the plurality of test workpieces, the software of the embedded system including an in-vehicle electronic control unit (ECU).

Description

Technical Field

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

[0002] A test platform in software testing may refer to information or parameters of a series of tools, processes, functional components, fixtures, etc. that enable a test to be executed under desired conditions, environments, or settings when compiled or utilized.

[0003] In some situations, a test platform may provide or define various test requirements such as hardware resources and / or software resources particularly required to provide a virtual environment, where the virtual environment simulates the actual environment in which the software is deployed and tested.

[0004] Resources used in a test platform for software testing may include requirements on hardware resources such as requirements on hardware components that enable software to interact properly to function properly. For example, in a vehicle embedded system, the hardware resources may include one or more physical electronic control units (ECUs: Electronic Control Unit) for the target ECU (e.g., the ECU under test) to interact with each other, one or more servers where associated data or information is hosted, and / or the like. In addition to hardware resources, a test platform for software testing may also include requirements related to software resources. For example, in a vehicle embedded system, the software resources may include one or more virtualized or emulated ECUs for the target ECU to interact with each other, one or more operating systems for executing the test, and / or the like.

[0005] In short, the relationship between a test platform and resources in software testing is that the test platform provides or defines the resources required to execute tests and evaluate the performance of software under various conditions. By simulating the actual environment or conditions in which the software is deployed, the test platform helps to identify and address all issues or defects in the software before it is deployed in the actual production environment, and to verify the accuracy of the soundness of the software design. This helps to ensure that the software is reliable, functions well, and meets the requirements.

[0006] Regarding this, the resources required for testing depend on the nature of the software to be tested and specific test requirements. For example, when the software to be tested requires a specific operating system or a specific hardware configuration, the test platform is required to include information on such resources to effectively test the software. Also, the test platform needs to be designed to handle specific types of tests to be performed, such as single-level tests, multi-level tests, etc. As an example, a test platform associated with a Software-In-the-Loop (SIL) test environment may also be different from a test platform associated with a Hardware-In-the-Loop (HIL) test environment.

[0007] Considering the above, to ensure efficient and effective testing, careful setting and design of the test platform are required. Nevertheless, as described below, the pre-configuration and utilization of test platforms for testing vehicle-related software are restricted, inefficient, and ineffective.

[0008] First, in the prior art, when testing software components involves specific hardware components (e.g., specific physical ECUs, etc.), it is usually required that the user visit a specific test facility where the specific hardware components are deployed, couple the software components to the hardware components, set the test platform accordingly, and then perform the test. Therefore, before the user can access the test platform, they need to physically move to a specific test facility, so accessing and utilizing the test platform takes time.

[0009] Moreover, the hardware deployed in the test facility is limited and restricted to a specific type or variant, so the number of possible parallel tests is small, it is difficult to build or set up the test platform on-site, and a test platform built for a specific vehicle variant cannot be used for other vehicle variants.

[0010] For example, since the hardware resources of the test facility are physically fixed and are often deployed in a black-box manner during testing (e.g., users of the test facility can ensure most (if not all) of the resources within the test facility), it is too difficult (if not impossible) for multiple users to utilize the test facility simultaneously. In addition, it is difficult (if not impossible) for users to perform multiple tests simultaneously through the test facility. Therefore, when a user has multiple tests to perform and / or when multiple users want to utilize the test facility, there are often problems of job conflicts, and users need to take turns (add reservations to a waiting list, etc.). However, this significantly delays the testing and ultimately delays the development of software (e.g., ECUs, etc.). Also, the configuration, adjustment, and testing among users are manually managed, which is inefficient and burdensome for users.

[0011] Moreover, when specific software components (e.g., a specific type of virtual ECU, a specific operating system, etc.) are required but cannot be utilized in a test facility, typically, the user needs to request the test facility manager to obtain the specific software components, and the manager needs to retrieve the requested software components and obtain the software components thereafter. This not only causes further delays in software testing but also incurs additional costs (human resources, expenses for obtaining the required software components, etc.).

[0012] Moreover, typically, a test platform is deployed to and provided for a test facility and is a general test platform that is predefined in most cases. Therefore, the user may need to frequently configure the test platform to meet the desired test requirements. Nevertheless, in the prior art, the user needs to manually configure the provided test platform, which is time-consuming, and sometimes the user needs to have a good technical understanding of the system to properly configure the test platform. In this regard, a user who does not have a good understanding or experience in configuring the test platform may not be able to configure the test platform efficiently and accurately and may cause the test to be inaccurate and lead to human errors.

[0013] The pre-configuration and utilization of a test platform become more difficult and complex when cross-domain testing is involved, which is a test required when developing advanced or complex functions of a vehicle system (e.g., lane change assistance, mobile intelligent key, etc.). This is because cross-domain testing involves testing multiple software components and hardware components across multiple systems, and as a result, it involves a considerable number of components, users / stakeholders, test requirements, etc., which increases the dynamic nature in test platform configuration and the resources required to perform cross-domain testing.

[0014] In the prior art, it is too difficult to appropriately and dynamically provide a test platform for ensuring resources for cross-domain testing. Instead, a considerable amount of time is required to collect the required information and configure the required software components / hardware components before configuring the test platform. Therefore, it takes time to prepare and execute cross-domain testing. Moreover, whenever a change occurs in cross-domain testing (e.g., an update of the software under test, a failure of a hardware component, etc.), the test platform needs to be redesigned or reconfigured, which may further delay the test and ultimately delay the software development. Also, since the requirements in resources may be dynamic and may change continuously (or occasionally), the resources ensured for cross-domain testing may be overprovisioning (which may result in waste of resources) or under-provisioning (which may lead to inefficient test execution and further delay in software development).

[0015] Given the above, the method for pre-configuring and utilizing a test platform for cross-domain testing in the prior art is limited, inefficient, and burdensome for users. Eventually, this may extend the lead time from the system-on-chip (SoC) technical specifications to the start of vehicle production (SOP: Start Of Production). 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 platforms for cross-domain testing for testing one or more software of a system. Specifically, the method, the system, the device, etc. of the exemplary embodiment can automatically obtain required information and automatically provide one or more test platforms as needed.

[0017] According to an embodiment, there can be provided a method for managing a test platform for cross-domain testing for testing software of an embedded system. This method can be implemented by at least one processor of the system, and this method can include: obtaining a test platform setting associated with software establishment; obtaining information on a plurality of test artifacts associated with the test platform setting; and generating a test platform associated with cross-domain testing based on the plurality of test artifacts (test artifact).

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

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

[0020] According to an embodiment, the method may further include: deploying at least one software component based on a test platform; ensuring at least one hardware component based on the test platform; 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 test equipment 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 the test platform; 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 deploying the at least one software component to the determined at least one node.

[0022] According to an embodiment, ensuring at least one hardware component may include: determining at least one hardware resource requirement based on the test platform; 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 ensuring the at least one hardware component.

[0023] According to an embodiment, creating a virtual vehicle model may include: determining the relationship between the at least one software component and the at least one hardware component based on the test platform; 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 providing a test platform for cross-domain testing for managing testing of software for an embedded system is provided. The system may include: at least one storage memory storing computer-executable instructions; and at least one processor communicatively coupled to the at least one storage memory and configured to execute the computer-executable instructions, wherein the computer-executable instructions are for the following processes: obtaining test platform settings associated with software establishment; obtaining information on a plurality of test artifacts associated with the test platform settings; and generating a test platform 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, wherein the computer-executable instructions are for obtaining the test platform settings by the following processes: receiving from a user one or more inputs defining the test platform; obtaining a component catalog containing information on available test artifacts; determining, based on the one or more inputs, one or more test artifacts associated with the user-defined test platform from among the available test artifacts; and constructing the test platform settings based on the determined one or more test artifacts.

[0026] According to an embodiment, the software of the embedded system may include an in-vehicle electronic control unit (ECU). In addition, 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 association model, and the at least one hardware component may include at least one physical ECU. Moreover, at least a portion of the plurality of test artifacts may be deployed at geographically different locations.

[0027] According to an embodiment, at least one processor may be configured to execute computer-executable instructions, wherein the computer-executable instructions are for the following processes: deploying at least one software component based on a test platform; ensuring at least one hardware component based on the test platform; and creating a virtual vehicle model based on the at least one software component and the at least one hardware component. In addition, at least one processor may further be configured to execute computer-executable instructions, wherein the computer-executable instructions are for the following process: generating test equipment 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, wherein the computer-executable instructions are for deploying at least one software component by the following process: determining at least one resource requirement for deploying the at least one software component based on the test platform; determining at least one node that meets the at least one resource requirement among a plurality of nodes communicatively coupled to the system; and deploying 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, wherein the computer-executable instructions are for ensuring at least one hardware component by the following process: determining at least one hardware resource requirement based on the test platform; determining at least one hardware component that meets the at least one hardware resource requirement among a plurality of hardware components communicatively coupled to the system; and ensuring the at least one hardware component.

[0030] According to an embodiment, at least one processor may be configured to execute computer-executable instructions, wherein the computer-executable instructions are for creating a virtual vehicle model by the following process: determining the relationship between at least one software component and at least one hardware component based on the test platform; 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, may be partially apparent from the description, or may be realized by practicing the presented embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Hereinafter, with reference to the accompanying drawings in which like reference numerals represent like elements, the features, advantages, and significance of exemplary embodiments of the present disclosure will be described.

[0033] Figure 1 is a block diagram of an exemplary system configuration for managing a test platform for cross-domain testing in one or more embodiments.

[0034] Figure 2 is a block diagram of exemplary components of a test platform management system in one or more embodiments.

[0035] Figure 3 is a flowchart of an exemplary method for facilitating pre-configuration of a test platform for cross-domain testing in one or more embodiments.

[0036] Figure 4 is a flowchart of an exemplary method for creating a virtual vehicle model in one or more embodiments.

[0037] Figure 5 is a block diagram of an exemplary test rig in one or more embodiments. Detailed Description

[0038] The following detailed description of exemplary embodiments refers to the accompanying drawings. The foregoing disclosure provides examples and descriptions, but is not intended to be exhaustive, nor is it intended to limit the implementation forms to the exact forms disclosed. Modifications and variations can be made, or can be obtained through the practice of the implementation forms, in view of the foregoing disclosure. Moreover, one or more features or components of one or more embodiments can be incorporated into another embodiment (or one or more features of another embodiment), or can be combined with it. Additionally, it can be understood that in the descriptions of the operations provided below, one or more operations can be omitted, one or more operations can be added, one or more operations can be (at least partially) executed simultaneously, and the order of one or more operations can be swapped.

[0039] Even if the features of a particular combination are recited in the claims and / or disclosed in the present specification, such a combination is not intended to limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not specifically recited in the claims and / or not disclosed in the present specification. Each of the dependent claims listed below can depend directly only on one claim, but the disclosure of possible implementations includes each dependent claim in combination with all the other claims within the claim set.

[0040] Unless expressly stated otherwise, no element, act, or instruction used in this specification should be construed as critical or essential. Also, as used in this specification, the articles "a" and "an" mean including one or more items and may be used interchangeably with "one or more". When only one item is meant, terms such as "one" or similar language are used. Also, as used in this specification, terms such as "has", "having", "include", "including", etc. mean unrestricted and open terms. Moreover, unless expressly stated otherwise, the phrase "based on" means "at least partially based on...". Also, 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 like terms are meant to include a particular feature, structure, or characteristic associated with the indicated embodiment 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 like terms throughout this specification may all refer to the same embodiment, but not necessarily so.

[0042] Moreover, the features, advantages, and characteristics of the present disclosure described may be combined in any suitable manner in one or more embodiments. Given the description of this specification, those skilled in the art should recognize 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 a particular embodiment that may not necessarily be present in all embodiments of the present disclosure.

[0043] Exemplary embodiments consistent with the present disclosure provide methods, systems, and apparatuses that facilitate the pre-configuration and / or utilization of at least one test platform for cross-domain testing for testing one or more software of one or more in-vehicle ECUs and other embedded systems.

[0044] Specifically, methods, systems, devices, etc. of exemplary embodiments can automatically provide one or more test platforms according to requirements. For example, methods, systems, devices, etc. of exemplary embodiments can automatically obtain one or more test platform settings and automatically generate one or more test platforms based on the one or more test platform settings. The one or more test platform settings can be associated with one or more user inputs that define the desired test platforms for software components and / or hardware components, etc. required for testing a specific software.

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

[0046] Therefore, methods, systems, devices, etc. of exemplary embodiments can continuously (or periodically) monitor the status of available test artifacts and resources and can appropriately generate and reconfigure one or more test platforms when needed based on real-time or near-real-time status and test requirements. As a result, one or more test platforms can be provided so that one or more test platforms 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 testing, and the required test platforms can be automatically and appropriately provided and configured in real-time or near-real-time without the user actually coming to the test facility. Ultimately, the exemplary embodiments of the present disclosure can enable the development of software to be carried out more efficiently, can greatly reduce the burden on the user, can greatly reduce the development time, and can greatly reduce the costs and labor for planning visits and business trips to the test facility.

[0048] It is expected that the features, advantages, and importance of the above-described exemplary embodiments are only a part of the present disclosure, and do not mean 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 their accompanying technical advantages and meanings, will be provided below.

[0049] Figure 1FIG. 100 is a block diagram of an exemplary system configuration for managing (pre-configuring, leveraging, etc.) a test platform for cross-domain testing for one or more embodiments. As Figure 1 shown, the system configuration 100 may include a test platform 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 platform management system 110 is communicatively coupled (via the network 130) to the plurality of nodes 120-1 to 120-N and communicatively coupled to the utilization party 140. The test platform management system 110 may be configured to interact with the plurality of nodes 120-1 to 120-N to provide a test platform (or one or more associated information or data) to the utilization party 140. Hereinafter, with reference to Figure 2 a description of exemplary components that may be included in the test platform management system 110 will be provided. Hereinafter, with reference to Figures 3 to 5 one or more operations that can be performed by the test platform management system 110 and associated use cases will be provided.

[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, deploying, processing, and / or providing one or more artifacts or components that make up the test platform.

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

[0053] According to an embodiment, one or more of the plurality of nodes 120-1 to 120-N may include one or more interfaces, and the one or more interfaces may be respectively configured to communicatively couple the associated nodes to the test platform 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 programming interface (API)), etc.

[0054] According to an embodiment, at least a part of the plurality of nodes 120-1 to 120-N may be located at a geographical location different from that of the test platform management system 110, a geographical location different from that of another part of the plurality of nodes, and / or a geographical location different from that of the user 140.

[0055] The network 130 may include one or more wired networks and / or wireless networks that may be configured to couple the plurality of nodes 120-1 to 120-N to the test platform management system 110. For example, the 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 line network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, etc. and / or a combination of these networks or other types of networks.

[0056] According to an embodiment, network 130 may include a virtual network, which may include one or more physical network components (e.g., Ethernet (registered trademark), WiFi (Wireless Fidelity) module, telecommunication network hardware, etc.) that implement one or more virtual network functions (e.g., Controller Area Network (CAN) bus, etc.). Additionally or alternatively, network 130 may include at least one parametric network. Further, according to an embodiment, network 130 may be configured to couple the test platform management system 110 (or one or more components included therein) to other components such as the utilization party 140, multiple test environments, one or more devices or equipment of a user (e.g., tester, etc.).

[0057] The utilization party 140 may include one or more systems, devices, etc., which may be configured to utilize one or more information or data provided by the test platform management system 110. According to an embodiment, the utilization party 140 may include a test management system, which may receive one or more test platforms (or associated information or data) from the test platform management system 110 and may utilize one or more test platforms (e.g., scheduling of tests, triggering of test execution, etc.) when managing one or more tests.

[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(virtual)-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.), which may utilize one or more test platforms provided by the test platform management system 110 when executing one or more tests. According to an embodiment, at least a part of nodes 120-1 to 120-N is associated with at least a part 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 be hosted (for execution) or deployed in a part of nodes 120-1 to 120-N where software-based components or artifacts are deployed. 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 a wireless connection and / or a wired connection) to a part of nodes 120-1 to 120-N associated with hardware-based components or artifacts.

[0059] Moreover, the utilization party 140 may also include one or more storage media such as a server or a server cluster, and the one or more storage media may be configured to save, disclose, etc. one or more test platforms (or information associated therewith) provided by the test platform management system 110.

[0060] Next, referring to Figure 2 , the Figure 2 is a block diagram showing exemplary components of a test platform management system 200 representing one or more embodiments. The test platform management system 200 may also correspond to the test platform management system 110 described above with reference to Figure 1 . Therefore, unless otherwise explicitly stated, the features described in this specification with reference to system 110 and system 200 may be applied to each other.

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

[0062] The communication interface 210 may include components such as a transceiver (e.g., a transceiver, a separate receiver and transmitter, etc.), and this component enables the test platform management system 200 (or one or more components included therein) to communicate with one or more external components of the test platform management system 200 via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection, etc. For example, the communication interface 210 may couple the test platform management system 200 (or one or more components included therein) to a plurality of nodes (e.g., Figure 1 nodes 120-1 to 120-N, etc. of

[0063] According to an embodiment, the communication interface 210 may include 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, and other hardware-based interfaces. According to an embodiment, the communication interface 210 may include at least one controller area network (CAN) bus, which may be configured to communicatively couple components of the test platform management system 200 (e.g., the memory 220, the processor 230, etc.) to a plurality of nodes (e.g., nodes 120-1 to 120-N) and / or at least one user (e.g., user 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 platform management system 200 and provide the information to the processor 230 for further processing and / or provide the information to the memory 220 for storage. For example, the communication interface 210 may read out the real-time or substantially real-time status of a task, obtain logs associated with task establishment, 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 memory 220 may include one or more storage media suitable for storing data, information, and / or computer-readable instructions / computer-executable instructions. According to an embodiment, the memory 220 may include a random access memory (RAM), a read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by the processor 230.

[0066] Additionally or alternatively, the memory 220 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state drive), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cassette tape, a magnetic tape, and / or other types of non-transitory computer-readable media, and include corresponding drives.

[0067] According to an embodiment, the memory 220 may operate as a centralized library and may be configured to store information used by the processor 230 to facilitate the pre-configuration or utilization of a test platform for cross-domain testing. For example, the memory 220 may be configured to store one or more test platform parameters or settings, such as one or more test conditions and information about one or more required software components / hardware components, predefined or pre-determined by one or more users. Further, the memory 220 may be configured to store one or more test artifacts, components, resource information, etc. that make up the test platform. Moreover, the memory 220 may 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 in this specification.

[0068] The at least one processor 230 may include one or more processors that may be programmed to perform functions or operations to facilitate the pre-configuration of cross-domain testing. For example, the processor 230 may be configured to execute computer-readable instructions stored in a storage medium (e.g., the memory 220, etc.) to perform one or more actions or one or more operations described in this specification.

[0069] According to an embodiment, the processor 230 may be configured to receive (e.g., via the communication interface 210, etc.) one or more signals that define one or more instructions for performing one or more operations. Further, the processor 230 may be implemented by 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 other types of processing or computing components.

[0070] According to an embodiment, the processor 230 may be configured to execute computer-executable instructions stored in at least one storage memory (e.g., the memory 220), thereby performing one or more operations for facilitating the pre-configuration and / or utilization of one or more test platforms.

[0071] Referring Figure 3 to Figure 3 , the flowchart of an exemplary method 300 for facilitating the pre-configuration of a test platform for cross-domain testing representing one or more embodiments is shown. One or more operations of the method 300 may be performed by at least one processor (e.g., the processor 230) of a test platform management system to facilitate the pre-configuration of a test platform for cross-domain testing for testing one or more software associated with an embedded system of a vehicle (e.g., one or more in-vehicle ECUs, etc.). It is to be understood that at least one processor may be configured to perform one or more operations of the method 300 for updating or reconfiguring one or more test platforms in the same manner as the methods described in this specification.

[0072] According to an embodiment, the method 300 may be initiated (triggered) in response to the detection of a change (e.g., an update, etc.) in one or more software being tested. Similarly, the method 300 may be initiated in response to the detection of a change in resources such as the detection of resources that may improve test performance, the detection of a failure (or the possibility of inoperability) of a hardware component, etc.

[0073] Referring Figure 3 to

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

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

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

[0077] Moreover, referring Figure 3 , when one or more test platform settings are obtained, method 300 may proceed to operation S320, and at least one processor of the test platform management system may be configured to obtain information about a plurality of test artifacts associated with the one or more test platform settings. According to an embodiment, the plurality of test artifacts may include at least one software component (e.g., a virtualized ECU, a vehicle association model, etc.), at least one hardware component (e.g., a physical ECU, etc.), or a combination thereof. Information about the plurality of test artifacts may include the availability of the test artifacts, the locations where the test artifacts are deployed or configured, access links associated with the test artifacts, and / or any other suitable information.

[0078] In several implementation forms, at least one processor may be configured to obtain information on a plurality of test artifacts from one or more nodes (e.g., nodes 120-1 to 120-N) communicatively coupled to the test platform management system in real time or substantially in real time. Additionally or alternatively, information on the plurality of test artifacts may be pre-obtained by at least one processor and may be stored in one or more storage media. In this case, in operation S320, at least one processor may access one or more storage media (e.g., via a communication interface) and may obtain information on the plurality of test artifacts from the one or more storage media.

[0079] Moreover, referring to Figure 3 , when information on the plurality of test artifacts is obtained, method 300 proceeds to operation S330, and at least one processor of the test platform management system may be configured to generate a test platform based on the information on the plurality of test artifacts and the obtained test platform settings.

[0080] For this purpose, at least one processor of the test platform management system may automatically and dynamically facilitate pre-configuration of one or more test platforms for testing (e.g., cross-domain testing) when needed.

[0081] When one or more test platforms are generated, at least one processor of the test platform management system may be configured to utilize the generated one or more test platforms.

[0082] According to an embodiment, at least one processor may provide one or more test platforms to a test management system for further processing. For example, the test management system may be configured to utilize one or more test platforms to perform one or more tests (e.g., cross-domain tests). Additionally, in this regard, it is to be understood that in several implementation forms, without departing from the technical scope of the present disclosure, the test platform management system may be configured to perform one or more operations that can be performed by the test management system described in this specification.

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

[0084] Moreover, at least one processor may be configured to continuously (or periodically) monitor the status of one or more test platforms that are stored / generated, and perform appropriate operations for managing the one or more test platforms. For example, at least one processor may continuously (or periodically) monitor the status (such as version, availability, etc.) of test artifacts associated with the one or more test platforms (e.g., by continuously or periodically requesting association information from one or more nodes via API calls, etc.), and may automatically reconfigure one or more test platforms when needed (e.g., based on a determination that an associated test artifact has been updated, a determination that an associated test artifact(s) is / are no longer available, etc.).

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

[0086] By creating a virtual vehicle model, a user may deploy one or more software on the virtual vehicle model, and the user may perform integration and testing as needed regardless of the user's geographical location and the components of the virtual vehicle model. In this way, before deploying the software to a physical test vehicle and ultimately to a customer's vehicle, the user may quickly and effectively ensure that the software operates as expected without causing regression.

[0087] With reference to Figure 4 , this Figure 4 represents a flowchart of an exemplary method 400 for creating a virtual vehicle model of one or more embodiments. One or more operations of method 400 may be performed by at least one processor (such as processor 230) of the test platform management system of the present disclosure, but it is understood that, without departing from the technical scope of the present disclosure, the one or more operations may also be performed by any other appropriate components of any other appropriate system when creating the virtual vehicle model. Moreover, one or more operations of method 400 may also be performed after one or more operations of method 300 (described in the narrative above with reference to Figure 3 ).

[0088] AsFigure 4 As shown, in operation S410, at least one processor of the test platform management system may be configured to deploy one or more software components associated with the establishment of one or more test platforms. According to an embodiment, the at least one processor may determine which software components (e.g., virtual ECUs, emulated ECUs, etc.) are defined within the one or more test platforms based on the one or more test platforms (e.g., test platforms obtained or generated by the method described above with reference to Figure 3 etc.), and accordingly obtain and execute the software components. For example, the software components may be deployed within one or more containers, and the 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, the at least one processor may determine one or more resource requirements for deploying one or more software components based on the one or more test platforms, and may determine one or more nodes that meet the one or more resource requirements from among a plurality of nodes or devices communicatively coupled to the test platform management system (e.g., Figure 1 nodes 120-1 to 120-N etc. as described above), and may deploy the one or more software components on the determined one or more nodes.

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

[0091] Moreover, with reference to Figure 4 , in operation S420, at least one processor of the test platform management system may be configured to ensure one or more hardware components associated with the establishment of one or more test platforms. According to an embodiment, the at least one processor may determine one or more hardware resource requirements (e.g., which hardware components (e.g., physical ECUs, etc.) are defined within the one or more test platforms) based on the one or more test platforms, and may determine one or more hardware components communicatively coupled to the test platform management system (e.g., Figure 1Among the nodes 120-1 to 120-N, etc., one or more hardware components that meet one or more hardware resource requirements (for example, one or more hardware components that can utilize and meet the hardware requirements defined in one or more test platforms) can be determined, and one or more hardware components can be ensured.

[0092] As an example, at least one processor can determine, based on one or more test platforms associated with the establishment of a virtual ECU, that the virtual ECU should interact with a physical ECU when performing functions. Therefore, 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 platform management system, and send a request for ensuring the physical ECU to the physical ECU. In this way, regardless of the geographical location where the physical ECU is deployed, at least one processor can dynamically ensure any physical ECU that meets the requirements defined by one or more test platforms.

[0093] It is to be understood that at least one processor can perform operation S410 and operation S420 in any suitable sequence. For example, without departing from the technical scope of the present disclosure, at least one processor can perform operation S410 and operation S420 in parallel, or can perform operation S420 before performing operation S410, etc. It is also to be understood that in several implementations, a node on which a software component is deployed can have a software-based test environment (for example, a SIL test environment, etc.) deployed therein, and a hardware component can be communicatively coupled to a hardware-based test environment (for example, a HIL test environment), and the software-based test environment and the hardware-based test environment can provide signals or information for simulating the actions of the software component / hardware component.

[0094] Moreover, referring to Figure 4 , in operation S430, at least one processor of the test platform management system can be configured to create a virtual vehicle model. According to an embodiment, at least one processor can determine the relationship or connection between a software component and a hardware component based on one or more test platforms, and then connect the software component to the hardware component based on the determined relationship, thereby creating a virtual vehicle model.

[0095] In several implementation forms, at least one processor may connect a software component to a hardware component through the following processes: determine a vehicle communication technical specification that defines the relationship between the software component and the hardware component based on one or more test platforms; generate a network connection setting based on the vehicle communication technical specification; and provide the network connection setting to one or more networks (e.g., network 130). Therefore, one or more networks may be configured to connect the software component to the hardware component based on the network connection setting when needed. In several embodiments, at least one processor may create a virtual network that defines the connection between the software component and the hardware component as if the software component and the hardware component communicate between actual vehicles according to the communication technical specification of the derived vehicle.

[0096] When a virtual vehicle model is created, at least one processor of the test platform management system may be configured to utilize the virtual vehicle model. For example, at least one processor may be configured to deploy one or more software under test to the virtual vehicle model (or provide the virtual vehicle model to the test management system) so as to perform cross-domain testing. As another example, at least one processor may provide the virtual vehicle model to one or more storage media (e.g., storage 220, external server, etc.) to store the virtual vehicle model for future use.

[0097] According to an embodiment, at least one processor of the test platform management system may be configured to generate a test rig based on the virtual vehicle model. In this regard, the test rig described in this specification may refer to one or more fixtures or components designated to systematically implement a specific test. In cross-domain testing, the test rig may refer to a specific test environment for performing cross-domain testing.

[0098] According to an embodiment, at least one processor of the test platform management system may be configured to generate a test rig through the following processes: create (in the same way as described above with reference to Figure 3 the method described) a virtual vehicle model based on one or more test platforms associated with the software (obtained in the same way as the method described above with reference to Figure 4 the method described); determine one or more test conditions based on the one or more test platforms; and connect the virtual vehicle model to the one or more test conditions.

[0099] One or more test conditions can be defined by a user and can include traffic conditions, meteorological conditions, urban conditions, and any other suitable types of conditions that are desired by the user for testing the software. In several implementations, at least one processor can also be configured to generate a test rig considering one or more test objectives defined by the user (e.g., target test execution time, target test result, etc.). In this regard, it can be understood that the parameters defined by the user such as the one or more test conditions and / or the one or more test objectives can be appropriately obtained by at least one processor (e.g., can be obtained from a user device in real-time or substantially in real-time, can be obtained from one or more storage media, etc.).

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

[0101] As Figure 5 shown, the test rig 500 can include a virtual vehicle model 510 and a plurality of simulation conditions 520, but it is to be understood that the test rig 500 can further include any other suitable components and / or can be configured in a manner different from the method as Figure 5 shown.

[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 driveline ECU, and at least one body ECU. The plurality of software components are communicatively coupled to the plurality of hardware components via a virtual network, and as a result, the plurality of software components can interact with each other in the same way as they communicate via a physical vehicle.

[0103] It is to be understood that in other implementation forms, one or more of the central ECU, the IC ECU, and the IVI ECU may be physical and hardware-based components, and / or one or more of the chassis ECU, the powertrain ECU, and the body ECU may be virtual and software-based components. Moreover, it is also to be understood that the virtual vehicle model 510 may include 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 additional components such as one or more additional components for further simulating the virtual vehicle model in a more realistic manner for the target vehicle.

[0104] Moreover, in Figure 5 the exemplary use cases, the multiple simulation conditions 520 include urban conditions, traffic conditions, and meteorological conditions, but it is to be understood that the multiple simulation conditions 520 may include any other suitable types of conditions as desired.

[0105] In view of the above, the test platform 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 perform cross-domain testing for testing the target software based on the created test rigs.

[0106] Moreover, the user can easily reset the cross-domain testing, for example, by providing a reconfigured version (e.g., an updated version, a different version, etc.) of the target software to the test platform management system, adding / deleting one or more test conditions, etc. The test platform management system can automatically update the test platform associated with the target software, and thus can update the associated test rigs in real time or substantially in real time.

[0107] Moreover, the test platform management system can continuously (or periodically) monitor the availability of software resources and hardware resources, and can automatically reconfigure the test equipment based on the determination that the currently utilized software resources and / or hardware resources are no longer optimal. For example, based on the determination that other devices on which software components can be deployed and which can provide better performance (e.g., higher computing power, etc.) are available, the test platform management system can redeploy the software components to the other devices. As another example, based on the determination that a hardware component is no longer available (e.g., due to unexpected hardware problems, etc.) or will soon be unavailable (e.g., due to reservations made by other users, etc.), the test platform management system can retrieve one or more other available hardware components that meet the requirements defined in the (one or more) test platforms and ensure the one or more other hardware components. In this way, the test platform management system can automatically reconfigure the test equipment based on real-time or near-real-time resource conditions, thereby ensuring that cross-domain testing can be executed without interruption.

[0108] It is to be understood that the specific order or hierarchy of the function boxes in the processes / flowcharts disclosed in this specification is an example of an exemplary method. It is to be understood that the specific order or hierarchy of the function boxes in the processes / flowcharts can be reconfigured based on design preferences. Moreover, several function boxes can be combined or omitted. The appended method claims present the elements of the various function boxes in an exemplary order and do not limit the elements of the various function boxes to the specific order or hierarchy presented.

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

[0110] A computer-readable storage medium can be an entity device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium is not limited to the following devices, for example, and can be 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 disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM (Erasable Programmable Read Only Memory) or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, punched card, or raised structures in a slot with instructions recorded thereon, etc., such machine-encoded devices, and any suitable combination of the above. Such computer-readable media used herein should not be construed as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated through a waveguide or other transmission medium (e.g., optical pulses passing through an optical fiber cable), or electrical signals transmitted through a wire, etc., such signals that are transient in themselves.

[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 via a network such as, for example, the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter or network interface in each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to store them in the computer-readable storage medium within each computing / processing device.

[0112] The computer-readable program code / instructions for performing the operations can be any one of assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source code or object code described in any combination of one or more programming languages, where the one or more programming languages include 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 can be executed entirely on the user's computer, can be executed partially on the user's computer, can be executed as a stand-alone software package, can be executed partially on the user's computer and partially on a remote computer, or can be executed entirely on a remote computer or server. In the latter case, 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 (e.g., using an Internet service provider to connect through the Internet) to an external computer. In several embodiments, to perform a solution or operation, an electronic circuit, such as a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), can utilize the state information of the computer-readable program instructions to personalize the electronic circuit, thereby executing the computer-readable program instructions.

[0113] These computer-readable program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device for the purpose of creating a machine, such that the instructions executed via the processor of the computer or other programmable data processing device create a component for implementing the functions / actions specified in the functional boxes of the flowchart and / or block diagram. Additionally, these computer-readable program instructions can be stored in a computer-readable storage medium, which can direct a computer, a programmable data processing device, and / or other devices to function in a particular manner, such that the computer-readable storage medium with the stored instructions constitutes an article of manufacture that includes instructions for implementing the solution of the functions / actions specified in the functional boxes of the flowchart and / or block diagram.

[0114] In addition, the computer-readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to generate a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions / actions specified in the functional blocks of the flowchart and / or block diagram.

[0115] The flowcharts and block diagrams in the accompanying drawings illustrate, by way of example, the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each functional block in the flowchart or block diagram may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function. The methods, computer systems, and computer-readable media may include additional functional blocks, fewer functional blocks, different functional blocks, or functional blocks configured differently from those shown in Figure 1 the figures. In several alternative implementations, the functions shown in the functional blocks may occur in a different order than shown in the figures. For example, two consecutive functional blocks shown may actually be executed simultaneously or substantially simultaneously, or sometimes the functional blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each functional block in the examples of the block diagrams and / or flowcharts, and combinations of functional blocks in the examples of the block diagrams and / or flowcharts, can be implemented by a special-purpose hardware-based system that performs the specified functions or actions, as well as by a combination of special-purpose hardware and computer instructions.

[0116] The systems and / or methods described in this specification 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 does not limit the implementation. Thus, it is understood that the operations and behaviors of the systems and / or methods are described in this specification without reference to specific software code, and that software and hardware can be designed to implement the systems and / or methods based on the description in this specification.

Claims

1. A method for managing a test platform for cross-domain testing, implemented by at least one processor of a system, wherein: The cross-domain test is a test performed on the software of the embedded system, and the method includes: Obtaining a test platform setting associated with the software; Obtaining information of a plurality of test artifacts associated with the test platform setting; and generating a test platform associated with the cross-domain test based on the plurality of test artifacts, The software of the embedded system includes an on-board electronic control unit ECU.

2. The method according to claim 1, wherein: Obtaining the test platform settings includes: receiving one or more inputs from a user defining a testbench; Obtaining a component catalog containing information about available test artifacts; Based on one or more inputs, determining one or more test artifacts associated with the user-defined test platform from the available test artifacts; and A test bench configuration is constructed based on the identified one or more test artifacts.

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

4. The method according to any one of claims 1 to 3, wherein: At least a portion of the plurality of test artifacts are deployed at geographically different sites.

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

6. The method according to claim 3 or 5, further comprising: deploying the at least one software component based on the test platform; ensuring the at least one hardware component based on the test platform; as well as A virtual vehicle model is created based on the at least one software component and the at least one hardware component.

7. The method according to claim 6, wherein: Deploying the at least one software component comprises: determining, based on the test platform, at least one resource requirement for deploying the at least one software component; determining at least one node satisfying the at least one resource requirement from among a plurality of nodes communicatively coupled to the system; and At least one software component is deployed on the determined at least one node.

8. The method according to claim 6 or 7, wherein: Ensure that the at least one hardware component includes: determining at least one hardware resource element based on the test platform; determining the at least one hardware component satisfying the at least one hardware resource requirement from among a plurality of hardware components communicatively coupled to the system; and The at least one hardware component is secured.

9. The method according to any one of claims 6 to 8, wherein: 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 platform; and At least one software component is connected to at least one hardware component based on the determined relationship.

10. The method according to any one of claims 6 to 9, further comprising: A test equipment for the cross-domain test is generated based on the virtual vehicle model.

11. A system for managing a test platform for cross-domain testing, wherein the cross-domain testing is a test performed on software of an embedded system, the system comprising: at least one storage memory storing computer executable instructions; as well as At least one processor is communicatively coupled to the at least one storage device and is configured to execute the computer executable instructions, wherein the computer executable instructions are used to: Obtaining a test platform setting associated with the software; Acquire information of a plurality of test artifacts associated with the test platform setting; as well as generating a test platform associated with the cross-domain test based on the plurality of test artifacts, The software of the embedded system includes an on-board electronic control unit ECU.

12. The system according to claim 11, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to obtain the test platform settings by: receiving one or more inputs from a user defining a testbench; Obtaining a component catalog containing information about available test artifacts; Based on one or more inputs, determining one or more test artifacts associated with the user-defined test platform from the available test artifacts; and A test bench configuration is constructed based on the identified one or more test artifacts.

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

14. A system according to any one of claims 11 to 13, wherein: At least a portion of the plurality of test artifacts are deployed at geographically different sites.

15. The system of claim 13, wherein: The at least one software component includes at least one virtual ECU, at least one simulated ECU or a vehicle-related model, The at least one hardware component includes at least one physical ECU.

16. The system according to claim 13 or 15, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to: deploying the at least one software component based on the test platform; ensuring the at least one hardware component based on the test platform; and A virtual vehicle model is created based on the at least one software component and the at least one hardware component.

17. The system of claim 16, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to deploy the at least one software component by: determining, based on the test platform, at least one resource requirement for deploying the at least one software component; determining at least one node satisfying the at least one resource requirement from among a plurality of nodes communicatively coupled to the system; and At least one software component is deployed on the determined at least one node.

18. The system according to claim 16 or 17, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to ensure that the at least one hardware component is: determining at least one hardware resource element based on the test platform; determining the at least one hardware component satisfying the at least one hardware resource requirement from among a plurality of hardware components communicatively coupled to the system; and The at least one hardware component is secured.

19. A system according to any one of claims 16 to 18, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to create the virtual vehicle model by: determining a relationship between at least one software component and at least one hardware component based on the test platform; and At least one software component is connected to at least one hardware component based on the determined relationship.

20. A system according to any one of claims 16 to 19, wherein: The at least one processor is further configured to execute the computer executable instructions, wherein the computer executable instructions are used to: A test equipment for the cross-domain test is generated based on the virtual vehicle model.

Images