System and method for preconfiguration of cross-domain testing

Abstract

The invention relates to a system and method for pre-configuration of cross-domain testing. The present disclosure provides methods, systems, and devices for facilitating pre-configuration for cross-domain testing for testing software of an embedded system. According to an embodiment, a method may be implemented by at least one processor, the method may include: detecting a change in software; acquiring a test configuration file associated with the software; acquiring a test platform based on the test configuration file; determining a plurality of test environments associated with the test platform; and performing the cross-domain test based on a plurality of test environments, the software of the embedded system may include an in-vehicle electronic control unit (ECU), and the plurality of test environments may include at least one software-in-loop (SIL) test environment and at least one hardware-in-loop (HIL) test environment.

Description

Technical Field

[0001] Systems and methods consistent with exemplary embodiments of the present disclosure relate to test provisioning, and more particularly, to systems and methods for provisioning different simulations and / or test environments for cross-domain testing. Background Art

[0002] In the past, various test environments have been introduced to test the functions and software performance of systems. As an example, an embedded system of a vehicle such as an electronic control unit (ECU) can be tested particularly by using at least one software-in-the-loop (SIL) test environment and at least one hardware-in-the-loop (HIL) test environment.

[0003] To develop advanced or complex functions within a system, testing of the functions and performance of multiple software and hardware components across multiple systems or domains is required. In a vehicle system, in the development of advanced functions such as lane change assistance and mobile intelligent key in the vehicle system, cross-domain testing may be required, and cross-domain testing may include testing the interaction between different ECUs and associated software and hardware components.

[0004] In short, cross-domain testing may refer to testing accompanied by the following processes: testing the functions of components across different domains or environments such as different operating environments, different system configurations, different hardware and / or software configurations, and / or the same items. The purpose of cross-domain testing is to ensure that system components function correctly across all these domains under different conditions.

[0005] Therefore, cross-domain testing may have the following characteristics.

[0006] (1) A minor change in the ECU may significantly affect the functions and stability of other associated ECUs and associated components, and careful integration management may be required between the components of the system. Therefore, integration problems often occur in cross-domain testing.

[0007] (2) Cross-domain testing sometimes requires specific hardware, software, and / or system configurations, and sometimes it is difficult or time-consuming to set up and maintain a test environment that accurately meets the test requirements. Therefore, cross-domain testing is mostly restricted by the test environment.

[0008] (3) Cross-domain testing often involves multiple users (e.g., teams, stakeholders, vehicle manufacturers, suppliers, dealers, etc.). These multiple users may be located in different places and may have different priorities, goals, backgrounds, communication modes, etc. Therefore, effective communication and collaboration are required to perform accurate cross-domain testing. As a result, communication and collaboration among users tend to become complex in cross-domain testing.

[0009] Given the above situation, in the prior art, whenever cross-domain testing is needed, multiple ECUs and associated software / hardware components need to be centrally configured in a unified testing facility (e.g., a local simulation / testing facility, etc.). The user / test leader physically accesses this testing facility and performs cross-domain testing therein. However, the method for performing cross-domain testing in the prior art has at least the following drawbacks.

[0010] First, the physical access of users to the testing facility is burdensome and time-consuming. For example, users are sometimes located in geographically different locations from the testing facility (e.g., different regions, different countries, etc.). Therefore, physically accessing the testing facility may require appropriate planning and may incur costs (e.g., users sometimes need to take a long flight to the testing facility, or sometimes need to collaborate appropriately with other associated users to schedule and reserve the testing facility, or sometimes need to apply for access visas and / or permits and spend time to obtain approval). In addition, the available equipment, hardware, etc. in the testing facility are limited. Therefore, users usually need to wait for a long time (e.g., enter a waiting list, etc.) before they can utilize the testing facility to perform cross-domain testing.

[0011] Moreover, in the prior art, it is difficult to quickly and accurately identify or discover breaking changes in cross-domain testing. Specifically, multiple components in the on-site testing facility may be changed after being used by different users (e.g., in addition to the components under test being changed, associated components may also be changed). Therefore, in the case where the component composition is not restored to the required state, the cross-domain testing performed based on multiple changed components may be inaccurate. Users sometimes cannot quickly and accurately identify breaking changes through cross-domain testing (e.g., problems caused by changes in the components under test may be discovered in cross-domain testing, but the problems may also be misinterpreted by users as problems caused by changes in other components. In addition, the problems may be modified due to changes in other components and thus not be discovered).

[0012] Moreover, in the prior art, the composition of the test facility is not flexible, and it is difficult to reconfigure cross-domain tests on-the-fly or on-demand. For example, even if the user / test leader requests to add a new ECU or change the ECU involved in the test facility, in the case where the requested ECU cannot be immediately utilized, the user / test leader may need to reserve the test facility again and wait until the next test, and then re-access the test facility to conduct further tests. Therefore, in the prior art, even if a destructive change is found during cross-domain testing, it is difficult to immediately modify the destructive change on the spot when it is discovered and re-execute the test immediately thereafter.

[0013] Considering the above situation, in the prior art, time is consumed during the execution of cross-domain tests, and most of the time is spent on travel arrangements, movement, sequential waiting for testing, etc. As a result, the method for executing cross-domain tests in the prior art is inefficient, cross-domain tests cannot be implemented on-demand in the prior art, and for users, executing cross-domain tests is a burden, and it is difficult to discover and immediately modify the destructive changes of the components in the test. Ultimately, these situations may extend the lead time from the technical specifications of the system-on-chip (SoC) to the start of vehicle production (SOP). Summary of the Invention

[0014] According to an embodiment, there are provided a method, a system, and a device for automatically facilitating cross-domain testing for testing one or more software of a system. For example, the method, the system, and the device can automatically determine whether the execution of the test should be started (triggered), automatically determine an appropriate test environment for executing the cross-domain test, and automatically execute the cross-domain test.

[0015] According to an embodiment, there is provided a method for facilitating the pre-configuration of cross-domain testing for testing the software of an embedded system. The method can be implemented by at least one processor and may include: detecting a change in the software; obtaining a test configuration file associated with the software; obtaining a test platform based on the test configuration file; determining a plurality of test environments associated with the test platform; and executing the cross-domain test based on the plurality of test environments. The software of the embedded system may include in-vehicle electronic control units (ECUs), and the plurality of test environments may include at least one software-in-the-loop (SIL) test environment and at least one hardware-in-the-loop (HIL) test environment.

[0016] According to an embodiment, the test configuration file may include information on multiple ECUs associated with the establishment of software and information on test environments respectively associated with the multiple ECUs. At least a part of the multiple ECUs may be associated with one or more nodes different from the software. In addition, at least a part of the multiple ECUs may be distributively configured at geographically different locations from the software. Moreover, the multiple ECUs may include at least one virtual ECU, at least one emulated ECU, at least one physical ECU, or a combination thereof. Further, in addition, the multiple ECUs may include at least one of a Central ECU (CECU), an Instrument Cluster (IC) ECU, an In-Vehicle Infotainment (IVI) ECU, and an Advanced Driver Assistance Systems (ADAS) ECU.

[0017] According to an embodiment, a change to the software may include a disruptive change. In addition, detecting a change to the software may include: obtaining information on the current state of the software from a node associated with the software; determining whether the software has been changed from a previous version based on the obtained state information; and determining whether the change is a disruptive change based on determining that the software has been changed.

[0018] According to an embodiment, determining multiple test environments may include: creating a test job including multiple tasks based on the obtained test platform; and selecting multiple test environments based on one or more requirements for executing the multiple tasks. In addition, performing cross-domain testing may include: allocating one or more tasks of the test job to the multiple test environments; receiving test results associated with the allocated one or more tasks from the multiple test environments; and generating a test result of the cross-domain testing based on the test results associated with the allocated one or more tasks.

[0019] According to an embodiment, a system is provided that facilitates pre - configuration for cross - domain testing for testing software of an embedded system. The system may include: at least one storage memory that stores 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: detecting a change in the software; obtaining a test configuration file associated with the software; obtaining a test platform based on the test configuration file; determining a plurality of test environments associated with the test platform; and performing cross - domain testing based on the plurality of test environments. The software of the embedded system may include an in - vehicle electronic control unit (ECU), and the plurality of test environments may include at least one software - in - loop (SIL) test environment and at least one hardware - in - loop (HIL) test environment.

[0020] According to an embodiment, the test configuration file may contain information on a plurality of ECUs associated with the software and information on test environments respectively associated with the plurality of ECUs. At least a portion of the plurality of ECUs may be associated with one or more nodes different from the software. In addition, at least a portion of the plurality of ECUs may be distributed at geographically different locations from the software. Moreover, the plurality of ECUs may include at least one virtual ECU, at least one emulated ECU, at least one physical ECU, or a combination thereof. Further, the plurality of ECUs may include at least one of a central ECU (CECU), an instrument cluster (IC) ECU, an in - vehicle infotainment (IVI) ECU, and an advanced driver assistance system (ADAS) ECU.

[0021] According to an embodiment, the change in the software may include a destructive change. In addition, the at least one processor may be configured to execute computer - executable instructions, wherein the computer - executable instructions are for detecting a change in the software through the following processes: obtaining information on the current state of the software from a node associated with the software; determining whether the software has been changed from a previous version based on the obtained state information; and determining whether the change is a destructive change based on the determination that the software has been changed.

[0022] According to an embodiment, at least one processor may be configured to execute computer-executable instructions, wherein the computer-executable instructions are used to determine multiple test environments through the following processes: creating a test job including multiple tasks based on the acquired test platform; and selecting multiple test environments based on one or more requirements for executing the multiple tasks. In addition, at least one processor may be configured to execute computer-executable instructions, wherein the computer-executable instructions are used to perform cross-domain testing through the following processes: assigning one or more tasks of the test job to multiple test environments; receiving test results associated with the assigned one or more tasks from the multiple test environments; and generating test results of the cross-domain testing based on the test results associated with the assigned one or more tasks.

[0023] Additional aspects are described in part in the following description, may be apparent in part from the description, or may be realized by practicing the presented embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] 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.

[0025] Figure 1 is a block diagram of an exemplary system configuration for facilitating pre-configuration of cross-domain testing in one or more embodiments.

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

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

[0028] Figure 4 is one or more embodiments related to Figure 3 a flowchart of an exemplary use case associated with operation S310.

[0029] Figure 5 is a flowchart of an exemplary method for selecting multiple test environments and performing cross-domain testing based thereon in one or more embodiments.

[0030] Figure 6 is one or more embodiments related to Figure 5 a flowchart of an exemplary use case associated with one or more operations of the method. DETAILED DESCRIPTION

[0031] Refer to the accompanying drawings for the following detailed description of an exemplary embodiment. The foregoing disclosure provides examples and descriptions, but is not intended to be exhaustive or to limit the implementations to the exact forms disclosed. Modifications and variations are possible in light of the above disclosure, or may be acquired through the practice of the implementations. Also, one or more features or components of one or more embodiments may be incorporated into (or one or more features of) another embodiment, or may be combined therewith. Additionally, it can be understood that in the following description of operations provided, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least in part) simultaneously, and the order of one or more operations may be switched.

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

[0033] Unless expressly stated otherwise, any element, operation, or instruction used in this specification should not 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". The term "one" or similar language is used when only one item is meant. Additionally, as used in this specification, terms such as "has", "having", "include", "including", etc. are meant to be open-ended terms without limitation. Also, unless expressly stated otherwise, the phrase "based on" means "at least in part 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.

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

[0035] Furthermore, 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 one or more of the specific 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.

[0036] Exemplary embodiments consistent with the present disclosure provide methods, systems, and apparatuses that facilitate pre-configuration for cross-domain testing for use in testing one or more software of an embedded system without geographical or location restrictions.

[0037] Specifically, the methods, systems, apparatuses, etc. of the exemplary embodiments can automatically detect one or more changes to one or more software of an embedded system and can accordingly automatically configure and execute cross-domain testing for testing one or more software. According to an embodiment, the methods, systems, apparatuses, etc. of the embodiment can automatically determine multiple test environments and perform cross-domain testing based on the multiple test environments. In several implementations, when one or more changes are detected, one or more configuration files associated with the one or more software can be obtained and a test bench can be obtained based on the one or more configuration files. Thus, multiple test environments can be determined based on the test bench, and the methods, systems, apparatuses, etc. of the exemplary embodiments can automatically assign one or more tasks to the multiple test environments for performing cross-domain testing regardless of where the multiple test environments and the components participating in the testing are located.

[0038] For this purpose, methods, systems, and apparatuses consistent with exemplary embodiments of the present disclosure facilitate the pre - configuration of a suitable test environment for cross - domain testing automatically and without geographical restrictions as needed. A user can remotely configure one or more conditions for initiating (triggering) a cross - domain test, and based on this, the execution of the cross - domain test can be automatically initiated without requiring the user to physically access the test facility. Moreover, disruptive changes can be quickly and easily discovered and modified, and the re - configured cross - domain test can be restarted or re - executed immediately when needed.

[0039] Ultimately, the exemplary embodiments of the present disclosure enable software development to be carried out more efficiently, significantly reduce the burden on users, greatly reduce development time, and substantially reduce the costs and labor for planning physical access to test facilities and business trips.

[0040] It can be expected that the features, advantages, and importance of the above - mentioned 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. Hereinafter, further descriptions of the features, components, configurations, operations, and implementations of the exemplary embodiments of the present disclosure are provided.

[0041] Figure 1 It is a block diagram of an exemplary system configuration 100 for facilitating the pre - configuration of cross - domain testing of one or more embodiments. As Figure 1 shown, the system configuration 100 may include a test management system 110, a plurality of nodes 120 - 1 to 120 - N, a network 130, and a plurality of test environments 140 - 1 to 140 - N.

[0042] Generally, the test management system 110 is communicatively coupled to the plurality of nodes 120 - 1 to 120 - N (via the network 130) and communicatively coupled to the plurality of test environments 140 - 1 to 140 - N. The test management system 110 may be configured to use the plurality of test environments to provide cross - domain testing for one or more components (e.g., virtual ECUs, physical ECUs, etc.) associated with the plurality of nodes. Hereinafter, with reference to Figure 2 an explanation of exemplary components that may be included in the test management system 110 is provided. Hereinafter, with reference to Figures 3 to 6 one or more operations that can be performed by the test management system 110 and associated use cases are provided.

[0043] Each of the plurality of nodes 120 - 1 to 120 - N may include one or more devices, equipment, systems, or any other suitable components that can receive, host, store, deploy, process, and / or provide one or more components constituting a system.

[0044] As an example, node 120-1 can include a device or equipment (e.g., a personal computer, a server or a server cluster, a workstation, etc.) that can be used for constructing, storing, executing, or simulating one or more computer-executable software applications of a vehicle system, such as one or more virtualized ECUs, one or more emulated ECUs, and / or any other suitable software-based components (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 can include one or more fully developed physical ECUs, one or more partially developed physical ECUs, one or more vehicle hardware components (e.g., a powertrain, etc.), or can be associated with them. Additionally or alternatively, the node can include one or more retarget equipment.

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

[0046] According to an embodiment, at least a portion of the plurality of nodes 120-1 to 120-N is located at one or more geographical locations different from the test management system 110, at one or more geographical locations different from another portion of the plurality of nodes, and / or at one or more geographical locations different from the plurality of test environments 140-1 to 140-N.

[0047] Network 130 may include one or more wired networks and / or wireless networks that may be configured to couple multiple nodes 120-1 to 120-N to test 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 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.

[0048] According to an embodiment, network 130 may include a virtual network that may include one or more physical network components (e.g., Ethernet (registered trademark), a WiFi (Wireless Fidelity) module, telecommunications network hardware, etc.) that implement one or more virtual network functions (e.g., a 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 test management system 110 (or one or more components included therein) to other components such as multiple test environments 140-1 to 140-N, one or more devices or equipment (e.g., testers, etc.) of a user, etc.

[0049] Multiple test environments 140-1 to 140-N may include at least one software-based test environment and / or at least one hardware-based test environment. According to an embodiment, at least one software-based test environment may include at least one Software-in-the-Loop (SIL) test environment, at least one Virtual ECU (V-ECU) test environment, at least one Model-in-the-Loop (MIL) test environment, at least one Processor-in-the-Loop (PIL) test environment, etc. According to an embodiment, at least one hardware-based test environment may include at least one Hardware-in-the-Loop (HIL) test environment. The test environments 140-1 to 140-N may be communicatively coupled to the test management system 110 respectively, providing one or more signals, information, data, etc. to the test management system 110, or receiving one or more signals, information, data, etc. from the test management system 110.

[0050] Generally, at least one hardware-based test environment may be configured to manage one or more tasks associated with one or more physical hardware components, such as the execution or simulation of tests associated with one or more physical hardware components, the scheduling of test execution, etc. (however, not limited thereto). For example, at least one hardware-based test environment may be communicatively coupled to one or more developed (or partially developed) hardware / physical components, and may simulate a real environment or an actual use case, thereby testing or evaluating one or more hardware / physical components.

[0051] As an example, a physical engine ECU may also be developed and tested before being embedded in a vehicle. In such an example, at least one hardware-based test environment may perform a simulation of the engine that interacts with the engine ECU, instead of testing the engine ECU with an actual engine. As another example, in-vehicle functions may include functions of software-based ECUs (e.g., virtual ECUs, emulated ECUs, etc.) and hardware-based ECUs. Therefore, at least one hardware-based test environment may be configured to interact with at least one software-based test environment via the test management system 110, providing cross-domain testing (e.g., at least one hardware-based test environment may perform tasks associated with establishing a relationship with a hardware-based ECU, and at least one software-based test environment may perform tasks associated with establishing a relationship with a software-based ECU, and the associated results may be collectively provided to the test management system 110 and then further processed).

[0052] On the other hand, at least one software-based test environment can be configured to manage one or more tasks associated with the execution or simulation of tests, the scheduling of test executions, etc. (however, not limited thereto) for one or more software components. In contrast to a hardware-based test environment that is communicatively coupled to and performs tests / simulations on one or more physical / hardware components, a software-based test environment can only obtain or receive one or more software components and perform software-based tests / simulations thereon. In short, a software-based test environment, like a hardware-based test environment, can be generated, deployed, and executed in any suitable computing device or environment without connecting to the physical / hardware components to be tested.

[0053] According to an embodiment, one or more software components that can be tested in at least one software-based test environment can include at least one virtual ECU and at least one emulated (or simulated) ECU. In this regard, at least one virtual ECU can be different from at least one emulated ECU in that the at least one virtual ECU can include (e.g., at the points of design, development, manufacturing, etc.) application software, programming code, functional algorithms, etc. that define a final ECU, while the emulated ECU can include application software, programming code, functional algorithms, etc. that define a general or non-final ECU. Moreover, at least one virtual ECU and / or at least one emulated ECU can include at least one of a central ECU (CECU), an instrument cluster (IC) ECU, an in-vehicle infotainment (IVI) ECU, an advanced driver assistance systems (ADAS) ECU, a chassis ECU, a driveline ECU, a body ECU, and any other suitable type of ECU associated with a vehicle.

[0054] Additionally or alternatively, one or more software components can include one or more software models such as at least one emulated environmental condition model (e.g., road condition model, traffic condition model, weather condition model, etc.), at least one vehicle-associated model (e.g., DCM model, HVAC model, etc.).

[0055] According to an embodiment, a software-based test environment can execute multiple tasks simultaneously (e.g., multiple tests, multiple simulations, etc.). For example, a software-based test environment can execute multiple tests / simulations in parallel for a software component (e.g., a virtual ECU, etc.), can execute one test / simulation in parallel for multiple software components, and / or can execute the same project. Moreover, a software-based test environment and a hardware-based test environment can execute multiple tasks simultaneously (e.g., multiple tests, multiple simulations, etc.). For example, a software-based test environment can execute one or more tests / simulations for one or more software components, while a hardware-based test environment can execute one or more tests / simulations for one or more hardware components (e.g., physical ECUs, etc.).

[0056] The multiple test environments 140-1 to 140-N can be configured to be executed by one or more test servers or can be communicatively coupled to one or more test servers. According to an embodiment, one or more of the multiple test environments 140-1 to 140-N can be deployed on one or more of the multiple nodes 120-1 to 120-N or can be configured to be executed on one or more of the multiple nodes 120-1 to 120-N. For example, a software-based test environment can be deployed on one or more of the multiple nodes 120-1 to 120-N and can be executed on one or more of the multiple nodes 120-1 to 120-N. Alternatively or additionally, one or more of the multiple test environments 140-1 to 140-N can be communicatively coupled (e.g., via wired coupling, wireless coupling, etc.) to one or more of the multiple nodes 120-1 to 120-N. For example, a hardware-based test environment can be communicatively coupled to a node associated with a physical ECU (e.g., a fully developed hardware ECU, a partially developed hardware ECU, etc.). In this case, as described above, one or more of the multiple test environments can be communicatively coupled to the test management system 110 via the network 130.

[0057] For this purpose, it can be understood that the above one or more software components and / or one or more hardware components (i.e., the components to be tested in the multiple test environments 140-1 to 140-N) are associated with one or more of the multiple nodes 120-1 to 120-N (e.g., are deployed on one or more of the multiple nodes 120-1 to 120-N, are communicatively coupled to one or more of the multiple nodes 120-1 to 120-N, etc.), and the test management system 110 can be configured to utilize the multiple nodes and the multiple test environments to facilitate the pre-configuration of cross-domain testing.

[0058] Next, referring to Figure 2 , thisFigure 2 FIG. is a block diagram showing exemplary components of a test management system 200 representing one or more embodiments. The test management system 200 may also correspond to the test 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 can be applied to each other.

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

[0060] The communication interface 210 may include components such as a transceiver (e.g., a transceiver, a separate receiver and transmitter, etc.), which enables the test management system 200 (or one or more components included therein) to communicate with one or more external components of the test 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 management system 200 (or one or more components included therein) to a plurality of test environments (e.g., Figure 1 test environments 140-1 to 140-N, etc.), thereby enabling them to communicate and interoperate with each other. As another example, the communication interface 210 may couple the test 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.), thereby enabling them to communicate with each other and interoperate. Similarly, the communication interface 210 may enable the components of the test management system 200 to communicate with each other. For example, the communication interface 210 may couple the memory 220 to the processor 230, thereby enabling them to communicate and interoperate with each other.

[0061] According to an embodiment, the communication interface 210 may include hardware-based interfaces such as a bus interface, an Ethernet (registered trademark) interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, a software interface, etc. According to an embodiment, the communication interface 210 may include at least one controller area network (CAN) bus, and the controller area network bus may be configured to communicatively couple components of the test 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 a plurality of test environments (e.g., test environments 140-1 to 140-N). Additionally or alternatively, the communication interface 210 may include software-based interfaces such as an application programming interface (API), a virtual network interface (e.g., a virtual CAN bus, etc.).

[0062] The 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 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 the processor 230. 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 another type of non-transitory computer-readable medium, and includes a corresponding drive.

[0063] 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 manage one or more tests (e.g., cross-domain tests, etc.). For example, the memory 220 may be configured to store one or more parameters or components such as test cycles, one or more test conditions, one or more configuration files, and / or the same items, etc., predefined or predetermined by one or more users (e.g., test leaders associated with establishing associations with one or more nodes). Moreover, the memory 220 may be configured to store information related to the capabilities and / or availability of each of the multiple test environments communicatively coupled to the test management system. For example, the capability information of the test server (or any other suitable node) of the deployed / hosted test environment, the processing capabilities of the simulators of the test environment (e.g., HIL simulator, SIL simulator, etc.), the history of test results, usage costs, processing / test speeds (or parameters that can determine processing / test speeds), etc. 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 described in this specification.

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

[0065] According to an embodiment, the processor 230 may be configured to receive (e.g., via the communication interface 210, etc.) one or more signals defining one or more instructions for performing one or more operations. Moreover, 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 another type of processing or computing component.

[0066] 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 managing one or more tests for one or more components (e.g., software and / or hardware components deployed in one or more of a plurality of nodes, or software and / or hardware components associated with one or more of a plurality of nodes).

[0067] Refer to Figure 3 , the Figure 3 flowchart of an exemplary method 300 for facilitating pre-configuration of cross-domain testing representing one or more embodiments. The method 300 may be executed by at least one processor (e.g., the processor 230) of a test management system to test one or more software associated with an embedded system of a vehicle (e.g., an in-vehicle ECU, etc.).

[0068] In operation S310, at least one processor of the test management system may be configured to determine whether the execution of a test should be started (triggered). For example, at least one processor may determine whether one or more conditions for executing the test are satisfied. One or more conditions may be predefined by one or more users (e.g., users associated with one or more of multiple nodes, etc.) and stored in one or more storage media (e.g., storage 220, etc.). As an example, one or more conditions may include meeting / violating one or more test requirements, reaching one or more thresholds, detecting one or more changes in software and / or one or more associated components (e.g., software / hardware components within a node, etc.).

[0069] According to an embodiment, at least one processor may determine whether one or more conditions for executing a test are satisfied by detecting changes in software (e.g., virtual ECU, etc.). For example, the at least one processor may determine whether the software has been changed from a previous version and determine whether the change is a breaking change. A description of an exemplary use case associated with operation S310 will be provided below with reference to Figure 4 to provide.

[0070] Therefore, based on determining that one or more conditions for executing a test are satisfied, at least one processor may determine that the execution of the test should be started, and method 300 may proceed to operation S320.

[0071] In operation S320, at least one processor may be configured to obtain a test platform. Generally, in software testing, a test platform may refer to a series of processes that provide the required test inputs, settings of test scenarios, and other information or parameters. For example, a test platform for testing an ECU may include information or parameters for the following processes: simulating the load for testing the ECU, or simulating one or more ECUs associated with the ECU, or simulating one or more test conditions (e.g., road conditions, weather conditions, etc.). According to an embodiment, the test platform may include a general test platform that defines the composition of the test environment for normal operation, and may include an instrumented test platform that defines the composition, conditions, and / or services (in addition to the general test platform) for testing specific functions or conditions.

[0072] According to an embodiment, in operation S320, at least one processor may obtain one or more test configuration files associated with the components to be tested (e.g., software components, hardware components, etc.), and may obtain the test platform based on the one or more test configuration files.

[0073] One or more test configuration files may include information or parameters that define one or more test configurations, such as mappings of the functionality of components and the types of test environments associated therewith (e.g., Function A of the first ECU should be tested in a software-based test environment, Function B of the first ECU should be tested in a hardware-based test environment, etc.), the resources required to test the functionality of the components (e.g., computing power, memory, etc.), load information associated with the functionality, etc.

[0074] According to an embodiment, one or more test configuration files may contain information about multiple ECUs (e.g., virtual ECUs, emulated ECUs, physical ECUs, etc.) associated with components (e.g., software) of the test object. The information may include the source code, algorithms, functionality, etc. of the multiple ECUs, and one or more test configuration files may contain information about test environments respectively established in association with the multiple ECUs. In some implementations, at least a portion of the multiple ECUs may be distributed at geographically different locations from the components of the test object. Alternatively or additionally, a portion of the multiple ECUs may be associated with one or more nodes different from the nodes of the components of the test object (e.g., configured to be executable / deployed in one or more nodes, or communicatively coupled to one or more nodes, etc.). Further, the multiple ECUs may also include at least one of a central ECU (CECU), an instrument cluster (IC) ECU, an in-vehicle infotainment (IVI) ECU, an advanced driver assistance systems (ADAS) ECU, and any other suitable types of ECUs.

[0075] Thus, at least one processor may obtain a test platform based on one or more test configuration files. According to an embodiment, the test platform may be generated in advance and stored in advance in one or more storage media (e.g., storage 220, external server, etc.). In operation S320, at least one processor may obtain the test platform from one or more storage media (based on one or more test configuration files). Instead, in operation S320, at least one processor may generate the test platform in real time or substantially in real time based on one or more test configuration files. According to an embodiment, at least one processor may obtain or generate a copy of the components associated with the components of the test object (e.g., a cloned version of the ECU associated with the components of the test object) and include the copy in the test platform.

[0076] When the test platform is acquired, the method 300 proceeds to step S330, where at least one processor of the test management system may be configured to determine to establish multiple test environments associated with the test platform. Figure 1 Similarly, the contents described in the multiple test environments 140-1 to 140-N may include at least one software-based test environment (e.g., a software-in-the-loop (SIL) test environment) and at least one hardware-based test environment (e.g., a hardware-in-the-loop (HIL) test environment). Next, when multiple test environments are determined, method 300 enters operation S340, and at least one processor may be configured to perform cross-domain testing based on multiple test environments. Descriptions of exemplary operations associated with operations S330 and S340 and exemplary use cases associated therewith will be described below with reference to Figure 5 and Figure 6 To provide.

[0077] Next, refer to Figure 4 , Figure 4 Indicates one or more embodiments and Figure 3 4. The flowchart of an exemplary use case associated with operation S310 of FIG. In the exemplary use case, the test management system 410 is configured to: continuously (or periodically) monitor the status of components (which may be multiple) deployed in the first node 420-1 and the second node 420-2 or associated with the first node 420-1 and the second node 420-2 according to the test cycles associated with the first node 420-1 and the second node 420-2, respectively, and determine whether to start the execution of the test in order to test the component (which may be multiple).

[0078] Here, Figure 4 The test management system 410 can be used with Figure 1 Test management system 110 and Figure 2 The test management system 200 corresponds to, Figure 4 The first node 420-1 and the second node 420-2 can be connected with Figure 1 The test management system 410 may include the test management system 410 as described above. Figure 2 at least one processor (e.g., processor 230), Figure 4 One or more operations of can be performed by at least one processor. Therefore, for the sake of brevity, redundant descriptions associated therewith are sometimes omitted below.

[0079] like Figure 4As shown, in operations S410-1 and S410-2, at least one processor of the test management system 410 can be configured to communicate with the first node 420-1. According to an embodiment, at least one processor can send (e.g., via an API call, etc.) a query or request for information about the current state of one or more components associated with the establishment of an association with the first node 420-1 (e.g., software components deployed on the first node 420-1 or software components configured to be executed (hosted) in the first node 420-1, hardware components communicatively coupled to the first node 420-1, etc.) to the first node 420-1. Thus, the first node 420-1 can provide the requested information to at least one processor of the test management system 410.

[0080] According to an embodiment, at least one processor can continuously (or periodically) perform operations S410-1 and S410-2 according to a first test cycle associated with the first node 420-1 and / or a first test cycle associated with one or more components associated with the first node 420-1. The first test cycle can be determined in advance by one or more users associated with the establishment of an association with the first node 420-1 (e.g., the administrator of the first node 420-1, the developer of the software component deployed on the first node 420-1, etc.), and the first test cycle can be stored in advance in one or more storage media (e.g., the storage of the test management system 410, an external server of the test management system 410, etc.).

[0081] As an example, the first test cycle can define that a first component associated with the establishment of an association with the first node 420-1 should be checked at time intervals such as every five minutes, every hour, every day, etc. Thus, at least one processor of the test management system 410 can perform operations S410-1 and S410-2 every five minutes, every hour, every day, etc. to obtain the latest status information of the first component from the first node 420-1. Moreover, at least one processor can perform operation S410-2 five minutes after the execution of operation S410-1 (or after other appropriate time intervals defined by the first test cycle), etc.

[0082] Assume that in operations S430-1 and S430-2, at least one processor of the test management system 410 can be configured to communicate with the second node 420-2 according to a second test cycle determined in advance by one or more users associated with the establishment of an association with the second node 420-2 in the same manner as described above with reference to operations S410-1 and S410-2, to request information about the current state of one or more components associated with the establishment of an association with the second node 420-2.

[0083] Moreover, it is understandable that the second test cycle (in which at least one processor executes operation S430-1 and operation S430-2) may be the same as or different from the first test cycle (in which at least one processor executes operation S410-1 and operation S410-2). Moreover, it is understandable that at least one processor may be configured to perform communication with the first node 420-1 (operation S410-1 and operation S410-2) and communication with the second node 420-2 (operation S430-1 and operation S430-2) in any suitable sequence. For example, without departing from the technical scope of the present disclosure, at least one processor may perform communication with the first node 420-1 and the second node 420-2 simultaneously (for example, operation S410-1 and operation S430-1 are executed in parallel, or operation S410-2 and operation S430-2 are executed in parallel, etc.), or may perform communication with the second node 420-2 before performing communication with the first node 420-1 (for example, operation S430-1 is executed before operation S410-1, etc.).

[0084] Moreover, referring to Figure 4 , when communicating with the first node 420-1 and the second node 420-2, at least one processor of the test management system 410 may be configured to determine whether the execution of the test should be started on the associated components based on information or data obtained from the first node 420-1 and the second node 420-2.

[0085] For example, in operation S420-1, at least one processor may determine whether one or more conditions for executing the test are satisfied. As an example, at least one processor may determine whether a change (relative to a previous version) has occurred in a component within the first node 420-1, and based on the determination that a change in the component has occurred, determine whether a breaking change has occurred.

[0086] In this regard, a "breaking change" may refer to a modification to software (or one or more associated components) that causes an existing function of the software to no longer function as expected or causes the function to become unstable. Moreover, a breaking change may be a change in the behavior of the software that affects other parts associated with the software (such as other software components, other hardware components, etc.) and results in a software failure. For this purpose, the conditions for determining a breaking change may be predefined in advance by a user associated with the component being tested, or may be predefined in advance by other users associated with the component being tested (such as users associated with other ECUs, where the other ECU is associated with the component being tested).

[0087] Thus, in operation S420-1, when a change in a component of a test object is detected, at least one processor may determine (based on one or more predefined conditions) whether the change is a destructive change, and may determine that the execution of a test for the component of the test object is required based on a determination that the change is a destructive change.

[0088] It can be understood that, in addition to or instead of determining a destructive change, at least one processor may determine whether any other condition is satisfied to determine whether the execution of a test should be initiated. For example, at least one processor may make a determination on whether the execution of a test should be initiated based on the following processes: determining whether the performance of an associated node (e.g., the first node 420-1) has decreased, whether a preset test execution schedule has been reached, etc. It should also be understood that at least one processor of the test management system may be configured to perform operations S440-1, operation S420-2, and operation S440-2 in the same manner as the method described above with reference to operation S420-1.

[0089] For this purpose, at least one processor of the test management system 410 may continuously (or periodically) determine, in an automated manner, whether the execution of a test should be initiated to test one or more components associated with one or more nodes.

[0090] Next, referring to Figure 5 this Figure 5 is a flowchart of an exemplary method 500 for selecting multiple test environments and thereby performing cross-domain testing, which represents one or more embodiments. One or more operations of method 500 may be Figure 3 part of operations S330 and S340, and may be performed by at least one processor (e.g., processor 230) of the test management system.

[0091] In operation S510, at least one processor of the test management system may be configured to create a test job. For example, at least one processor may create a test job including multiple tasks based on a test platform (e.g., obtained in operation S320), and the multiple tasks may each contain information (e.g., requirements, etc.) associated with the test to be executed.

[0092] As an example, if it is assumed that in order to test the changed / modified software (e.g., the modified virtual ECU) in a software-based test environment (e.g., SIL test environment) and a hardware-based test environment (e.g., HIL test environment), cross-domain testing needs to be performed, at least one processor can create a cross-domain test job including multiple tasks, where the multiple tasks respectively contain information such as runtime information, information on required hardware resources (e.g., the type of required physical ECU, etc.), information on required software resources (e.g., CPU power, memory, etc.), information on copies of components, etc. The cross-domain test job can be utilized by at least one processor to determine the best software-based test environment and the best hardware-based test environment for performing cross-domain testing.

[0093] When the test job is created, the method 500 proceeds to operation S520, and at least one processor of the test management system can be configured to select multiple test environments for performing the test based on the created test job.

[0094] As an example, when it is assumed that (as described above with reference to operation S510) a cross-domain test job is created, at least one processor can determine the test environment requirements for each task for performing the test based on one or more requirements of the tasks for performing the cross-domain test job. Then, at least one processor can select an appropriate or best test environment for the tasks of performing the cross-domain test job from among multiple test environments (e.g., multiple test environments 140-1 to 140-N) communicatively coupled to the test management system.

[0095] For example, at least one processor can select one or more software-based test environments that can be used for performing software-based testing and meet the required requirements (e.g., software resource requirements, etc.) from among multiple software-based test environments communicatively coupled to the test management system, and at least one processor can select one or more hardware-based test environments that are available and meet the required requirements (e.g., hardware resource requirements, etc.) from among multiple hardware-based test environments communicatively coupled to the test management system.

[0096] When the test environment is selected, the method 500 proceeds to operation S530, and at least one processor of the test management system can be configured to assign one or more tasks to the selected test environment. Thus, the test environment can execute the assigned tasks, and then provide the execution results to at least one processor. Then, at least one processor can generate (e.g., compile, assemble, etc.) the test results of the cross-domain test based on the test results provided by the multiple test environments associated with the assigned tasks.

[0097] Next, with reference toFigure 6 , this Figure 6 represents a flowchart of an exemplary use case associated with one or more operations of a method of Figure 5 . In this exemplary use case, the test management system 610 is communicatively coupled to a plurality of test servers 620-1 to 620-N, and the test management system 610 is configured to select one or more test environments associated with establishing associations with the plurality of test servers, thereby facilitating the pre-configuration of cross-domain testing.

[0098] At this point, it can be understood that Figure 6 the test management system 610 of Figure 1 corresponds to the test management system 110 of Figure 2 , the test management system 200 of Figure 4 or Figure 4 the test management system 410 of Figure 1 , and one or more of the plurality of test servers 620-1 to 620-N can be respectively associated with more than one of the plurality of test environments 140-1 to 140-N of .

[0099] Moreover, it can be understood that the test management system 610 may include at least one processor (e.g., processor 230), Figure 6 one or more of the operations in Figure 6 can be performed by at least one processor. Moreover, it can also be understood that Figure 6 one or more of the operations in Figure 3 can be performed after Figure 3 and Figure 4 one or more of the operations in .

[0100] Referring to Figure 6 , in operation S610, at least one processor of the test management system 610 can be configured to create a test job. The details of this operation are the same as those described in operation S510 of Figure 5 , so for the sake of brevity of description, hereinafter, repeated descriptions may sometimes be omitted.

[0101] When a test job is created, at least one processor of the test management system 610 can be configured to communicate with the plurality of test servers 620-1 to 620-N (respectively in operations S620-1 to S620-N) to obtain information about the associated test environment.

[0102] In Figure 6 Figure 6 ​​​​​​​​​​In an exemplary use case, at least one processor may first (in operation S620-1) obtain availability information, capability information, and / or any other suitable type of information related to one or more test environments associated with the first test server 620-1 (e.g., set to be executable / deployed in the first test server 620-1, communicatively coupled to the first test server 620-1, etc.) from the first test server 620-1. For example, at least one processor may generate one or more API calls to request the requested information from the first test server 620-1 and may provide the generated API calls to the first test server 620-1 (via a communication interface). Thus, at least one processor may obtain the required information from the remaining test servers 620-2 to 620-N in the same manner.

[0103] It can be understood that, in addition, at least one processor of the test management system 610 may obtain the required information from the multiple test servers 620-1 to 620-N in any suitable order. For example, at least one processor may perform operation S620-1 and operation S620-2 simultaneously to obtain the required information about multiple test environments associated with establishing connections with the first test server 620-1 and the second test server 620-2, or may perform operation S620-2 before operation S620-1 to first obtain the capability information from the second test server 620-2.

[0104] When the required information is received from the multiple test servers, in operation S630, at least one processor of the test management system 610 may be configured to select, from among the multiple test environments associated with establishing connections with the multiple test servers, multiple test environments that are suitable or optimal for performing one or more tasks of the created test job.

[0105] For example, at least one processor may select (select or choose) multiple test environments according to the requested information (e.g., availability, capability, cost, etc.) and the types of test environments required for performing one or more tasks of the test job (e.g., hardware-based test environments such as HIL test environments, software-based test environments such as SIL test environments, V-ECU test environments, etc.).

[0106] As an example, if it is assumed that the test job is a cross-domain test job including a first task and a second task, where the first task is a task for testing A as a virtual ECU in a SIL test environment with a CPU power requirement of X, the second task is a task for testing B as a physical ECU, etc., and the task for testing A as a virtual ECU, then at least one processor can select, from among the test servers 620-1 to 620-N, one or more test environments within the test server that have sufficient CPU power and can perform the SIL test as needed in the first task. Similarly, at least one processor can select, from among the test servers 620-1 to 620-N, one or more test environments within the test server that can establish an association with B as a physical ECU and perform a HIL test on B as a physical ECU as required in the second task. It is to be understood that, without departing from the technical scope of the present disclosure, at least one processor can perform any other suitable operations for selecting a suitable test environment for performing one or more tasks of the created test job.

[0107] When multiple test environments are selected, at least one processor can be configured to assign or allocate the tasks of the test job to each test environment. In Figure 6 the exemplary use case, it can be assumed that a first test environment (e.g., a SIL test environment) associated with the first test server 620-1 is selected to perform the first task of the test job, and a second test environment (e.g., a HIL test environment) associated with the second test server 620-2 is selected by at least one processor to perform the second task of the test job. Therefore, in operations S640-1 and S640-2, at least one processor can be configured to assign or allocate the first task and the second task to the first test environment and the second test environment, respectively.

[0108] According to an embodiment, at least one processor can be configured to assign or allocate the tasks of the test job by generating signals, messages, instructions, etc. that include information about the tasks (e.g., the schedule for performing the tasks, the target completion time of the tasks, etc.). According to an embodiment where the task includes testing other software components (e.g., other virtual ECUs, emulated ECUs, software models such as traffic models, etc.), the signals, messages, instructions, etc. generated by at least one processor can further include copies of the other software components (e.g., cloned versions of source code, algorithms, etc.). Thereafter, at least one processor can provide the generated signal / message / instruction to the test server configured to execute or deploy the selected test environment.

[0109] Regarding this, at least one processor of the test management system 610 can first assign a task to a first test environment (operation S640-1), which is set to be executable in the first test server 620-1 or can be deployed in the first test server 620-1. Then, a task can be assigned to a second test environment (operation S640-2), which is set to be executable in the second test server 620-2 or can be deployed in the second test server 620-2. Alternatively, at least one processor can dispatch multiple tasks for simultaneous execution in the first test environment and the second test environment. It can be understood that, in addition, at least one processor can dispatch or assign tasks in any other appropriate sequence.

[0110] When one or more tasks are dispatched or assigned to a test environment, the test environment can perform one or more tests according to the assigned tasks. Then, in operations S650-1 and S650-2, at least one processor of the test management system 610 can be configured to monitor the performance of the test environment, can receive one or more test results of the assigned tasks from the test server, etc., and can update the associated information in the record file accordingly. For example, at least one processor can collect the test results provided by multiple test environments and generate or compile a complete and comprehensive test result representing the test results of cross-domain tests.

[0111] As another example, whenever one or more test results indicate a failure of test execution (such as a failure due to an exception or timeout for not completing a task within the specified period, etc.), at least one processor can update the record file so as not to reassign similar tasks to the same test environment in future tests. Similarly, whenever one or more test results indicate a specific parameter (such as time or speed) different from the parameters inferred from the record or reflected in the record, at least one processor can update the record file accordingly to more accurately reflect the latest capabilities of the corresponding test environment.

[0112] In addition, when receiving a report of task failure or determining that a task has failed, at least one processor can be configured to reassign the failed task to another test environment. For example, whenever a task failure is reported due to timeout, at least one processor can reassign the task to another test environment, and the associated capability information of the other test environment shows a test speed higher than that of the test environment to which the task was previously assigned.

[0113] In view of the above, it can be understood that at least one processor can be configured to allocate one or more tasks based on the test results of previous tests. For example, a first series of tests or simulations are performed to test a software component (e.g., a virtual ECU), and thereafter, the source code of the software component is updated. In this regard, at least one processor can optimize the task allocation for testing the software component using the updated source code in a second series of tests or simulations (e.g., shortening the test execution time, etc.) based on the results of the first series of tests or simulations.

[0114] It is to be understood that the specific order or hierarchy of the functional blocks 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 functional blocks in the processes / flowcharts can be reconfigured based on design preferences. Moreover, several functional blocks can be combined or omitted. The appended method claims present the elements of the various functional blocks in an exemplary order and do not limit the elements of the various functional blocks to the specific order or hierarchy presented.

[0115] Several embodiments can relate to systems, methods, and / or computer-readable media at any possible level of detail of integration of any of the technologies. 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.

[0116] 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 a raised structure in a slot with recorded instructions, etc., such machine-encoded devices, and any suitable combination of the above. Such computer-readable media used in this specification should not be construed as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated through waveguides or other transmission media (e.g., light pulses passing through an optical fiber cable), or electrical signals transmitted through wires, etc., such signals that are transient in themselves.

[0117] The computer-readable program instructions described in this specification 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 a computer-readable storage medium within each computing / processing device.

[0118] The computer-readable program code / instructions for performing operations can be any one of assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, constitution data for integrated circuits, or source code or object code described in any combination of one or more programming languages. 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 in whole on the user's computer, can be executed in part on the user's computer, can be executed as an independent software package, can be executed in part on the user's computer and in part on a remote computer, or can be executed in whole 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., by using an Internet service provider to connect through the Internet) to an external computer. In several embodiments, in order to execute a scheme 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 status information of the computer-readable program instructions to personalize the electronic circuit, thereby executing the computer-readable program instructions.

[0119] 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 in order to produce a machine, so 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 function boxes of the flowchart and / or block diagram. In addition, 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, so that the computer-readable storage medium with the stored instructions constitutes an article of manufacture, which contains instructions for implementing the scheme of the functions / actions specified in the function boxes of the flowchart and / or block diagram.

[0120] 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 boxes of the flowchart and / or block diagram.

[0121] 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 box 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 boxes, fewer functional boxes, different functional boxes, or functional boxes configured differently from those shown in Figure 1 what is illustrated. In some alternative implementations, the functions shown in the functional boxes may occur in a different order than shown in the figures. For example, two consecutive functional boxes shown may actually be executed simultaneously or substantially simultaneously, or sometimes the functional boxes may be executed in the reverse order, depending on the functionality involved. It should also be noted that each functional box in the examples of the block diagrams and / or flowcharts, and combinations of functional boxes 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, and that combines special-purpose hardware and computer instructions.

[0122] 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 preconfiguration of a cross-domain test is implemented by at least one processor to facilitate preconfiguration of a cross-domain test for testing software of an embedded system, the method comprising: detecting changes to the software; Obtaining a test configuration file associated with the software; Acquire a test platform based on the test configuration file; Determining to establish a plurality of test environments associated with the test platform; as well as Executing the cross-domain test based on the multiple test environments, The software of the embedded system includes an on-board electronic control unit ECU, The multiple test environments include at least one software-in-the-loop (SIL) test environment and at least one hardware-in-the-loop (HIL) test environment.

2. The method according to claim 1, wherein: Changes to the software include destructive changes.

3. The method according to claim 1 or 2, wherein: The test configuration file includes information of a plurality of ECUs associated with the software and information of test environments associated with the plurality of ECUs, respectively.

4. The method according to claim 3, wherein: At least a portion of the plurality of ECUs are associated with one or more nodes different from the software.

5. The method according to claim 3, wherein: At least a part of the plurality of ECUs is disposed in a dispersed manner at a location geographically different from the software.

6. The method according to claim 3, wherein: The multiple ECUs include at least one virtual ECU, at least one simulated ECU, at least one physical ECU, or a combination thereof.

7. The method according to claim 3, wherein: The plurality of ECUs include at least one of a central ECU (CECU), an instrument cluster ECU (ICECU), an in-vehicle infotainment ECU (IVIECU), and an advanced driver assistance system ECU (ADASECU).

8. The method according to any one of claims 1 to 7, wherein: Detecting changes to the software includes: Acquire information about the current state of the software from a node associated with the software; determining whether the software has been changed from a previous version based on the acquired status information; and Based on the determination that the software has been changed, a determination is made as to whether the change is a destructive change.

9. The method according to any one of claims 1 to 8, wherein: Determining the plurality of test environments comprises: Creating a test job including multiple tasks based on the acquired test platform; and The plurality of test environments are selected based on one or more requirements for performing the plurality of tasks.

10. The method according to claim 9, wherein: Executing the cross-domain test includes: assigning one or more tasks of the test job to the plurality of test environments; receiving test results associated with the assigned one or more tasks from the plurality of test environments; and A test result of the cross-domain test is generated based on the test result associated with the assigned one or more tasks.

11. A system for pre-configuration of cross-domain testing, which is a system for facilitating pre-configuration of cross-domain testing for testing 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: detecting changes to the software; Obtaining a test configuration file associated with the software; Acquire a test platform based on the test configuration file; determining to establish a plurality of test environments associated with the test platform; and Executing the cross-domain test based on the multiple test environments, The software of the embedded system includes an on-board electronic control unit ECU, The multiple test environments include at least one software-in-the-loop (SIL) test environment and at least one hardware-in-the-loop (HIL) test environment.

12. The system according to claim 11, wherein: Changes to the software include destructive changes.

13. The system according to claim 11 or 12, wherein: The test configuration file includes information of a plurality of ECUs associated with the software and information of test environments associated with the plurality of ECUs, respectively.

14. The system according to claim 13, wherein: At least a portion of the plurality of ECUs are associated with one or more nodes different from the software.

15. The system of claim 13, wherein: At least a part of the plurality of ECUs is disposed in a dispersed manner at a location geographically different from the software.

16. The system of claim 13, wherein: The multiple ECUs include at least one virtual ECU, at least one simulated ECU, at least one physical ECU, or a combination thereof.

17. The system of claim 13, wherein: The plurality of ECUs include at least one of a central ECU (CECU), an instrument cluster ECU (ICECU), an in-vehicle infotainment ECU (IVIECU), and an advanced driver assistance system ECU (ADASECU).

18. A system according to any one of claims 11 to 17, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to detect the change of the software by: Acquire information about the current state of the software from a node associated with the software; determining whether the software has been changed from a previous version based on the acquired status information; and Based on the determination that the software has been changed, a determination is made as to whether the change is a destructive change.

19. A system according to any one of claims 11 to 18, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to determine the plurality of test environments by: Creating a test job including multiple tasks based on the acquired test platform; and The plurality of test environments are selected based on one or more requirements for performing the plurality of tasks.

20. The system of claim 19, wherein: The at least one processor is configured to execute the computer executable instructions, wherein the computer executable instructions are used to perform the cross-domain test by: assigning one or more tasks of the test job to the plurality of test environments; receiving test results associated with the assigned one or more tasks from the plurality of test environments; and A test result of the cross-domain test is generated based on the test result associated with the assigned one or more tasks.

Images