An emulation test method, apparatus, and electronic device

Abstract

Embodiments of the present application disclose a simulation test method and device and electronic equipment. The method comprises: after receiving a user request and determining a to-be-tested service, determining a simulation control domain scenario and a target simulation service based on the to-be-tested service; configuring an auxiliary service in the simulation control domain scenario based on the to-be-tested service; and performing simulation test on the to-be-tested service based on the auxiliary service and the target simulation service. Through the above manner, the simulation control domain scenario, the target simulation service and the auxiliary service are determined based on the to-be-tested service, the simulation test is performed on the to-be-tested service, the auxiliary service is configured in the simulation control domain scenario for realizing a complete test closed loop, the service serves as a message middleware between the simulation control domain and the vehicle cabin domain, the communication link is ensured to be smooth, the to-be-tested service is verified in all directions, the simulation test on the to-be-tested service in the vehicle cabin domain can be completed without relying on a real bench or test vehicle, and thus the test efficiency is significantly improved.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more specifically, to a simulation testing method, apparatus, and electronic equipment. Background Technology

[0002] With the continuous development of vehicle technology, intelligent connectivity has become an important direction for the future development of automobiles. Data interaction between various domain controllers is becoming more frequent and the data volume is increasing. In related approaches, Data Distribution Service (DDS) can be used as a communication middleware between the intelligent cockpit domain and the body control domain to realize data interaction between the two domains. However, in this approach, because the functional testing during the development of DDS services in the intelligent cockpit domain relies on real benchtops or test vehicles, there is still a problem of low testing efficiency. Summary of the Invention

[0003] In view of the above problems, this application proposes a simulation testing method, apparatus, and electronic device to improve the above problems.

[0004] Firstly, this application provides a simulation testing method, the method comprising: The system receives a user request and identifies a service to be tested, which represents a service deployed in the vehicle cockpit domain that needs to be tested. Based on the service to be tested, it determines a simulation control domain scenario and a target simulation service within the simulation control domain scenario. The simulation control domain scenario includes multiple simulation services, each representing a simulated service corresponding to a service deployed in the vehicle cockpit domain, and the target simulation service representing a simulated service corresponding to the service to be tested. Based on the service to be tested, it configures an auxiliary service within the simulation control domain scenario, which is a message middleware between the simulation control domain and the vehicle cockpit domain. Based on the auxiliary service and the target simulation service, it performs simulation testing on the service to be tested within the simulation control domain scenario.

[0005] Secondly, this application provides a simulation testing method apparatus, the apparatus comprising: The simulation test preparation unit is used to receive user requests to determine the service to be tested, wherein the service to be tested represents the service that needs to be tested among the services deployed in the vehicle cockpit domain; based on the service to be tested, determine the simulation control domain scenario and the target simulation service in the simulation control domain scenario, wherein the simulation control domain scenario includes multiple simulation services, wherein the simulation service represents the simulation service corresponding to the service deployed in the vehicle cockpit domain, and the target simulation service represents the simulation service corresponding to the service to be tested; based on the service to be tested, configure auxiliary services in the simulation control domain scenario, wherein the auxiliary services are message middleware between the simulation control domain and the vehicle cockpit domain; and the simulation test execution unit is used to perform simulation tests on the service to be tested in the simulation control domain scenario based on the auxiliary services and the target simulation services.

[0006] Thirdly, this application provides an electronic device including one or more processors and a memory; one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs being configured to perform the methods described above.

[0007] Fourthly, this application provides a computer-readable storage medium storing program code, wherein the above-described method is executed when the program code is run.

[0008] This application provides a simulation testing method, apparatus, electronic device, and storage medium. Upon receiving a user request and determining the service to be tested, it determines a simulation control domain scenario and a target simulation service within the simulation control domain scenario based on the service to be tested. The simulation control domain scenario includes multiple simulation services, each representing a simulated service corresponding to a service deployed in a vehicle cockpit domain, and the target simulation service representing a simulated service corresponding to the service to be tested. Based on the service to be tested, an auxiliary service is configured within the simulation control domain scenario. The auxiliary service is a message middleware between the simulation control domain and the vehicle cockpit domain. Based on the auxiliary service and the target simulation service, simulation testing is performed on the service to be tested within the simulation control domain scenario.

[0009] In this application, the above-described method enables the determination of a simulation control domain scenario and a target simulation service within that scenario based on the service under test (SUPT). An auxiliary service is then configured within the simulation control domain scenario based on the SUPT, allowing for simulation testing of the SUPT within the simulation control domain scenario based on both the auxiliary service and the target simulation service. To achieve a complete test loop, an auxiliary service is configured within the simulation control domain scenario. This auxiliary service acts as a message middleware between the simulation control domain and the vehicle cockpit domain, ensuring uninterrupted communication and enabling comprehensive verification of the SUPT. This eliminates the need for a real test bench or test vehicle, allowing for simulation testing of the SUPT in the vehicle cockpit domain and significantly improving testing efficiency. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart of a simulation testing method proposed in an embodiment of this application is shown; Figure 2 This illustration shows a communication diagram of a real-world EDC-VIU according to an embodiment of this application; Figure 3 This can be a communication diagram of an EDC-simulated VIU under a simulation test proposed in an embodiment of this application; Figure 4 A schematic diagram illustrating a mapping relationship proposed in an embodiment of this application is shown; Figure 5 A flowchart of a simulation testing method proposed in an embodiment of this application is shown; Figure 6 A flowchart of a source code compilation method proposed in an embodiment of this application is shown; Figure 7 A flowchart of a preferred source code compilation method proposed in an embodiment of this application is shown; Figure 8 A flowchart of a preferred simulation testing method proposed in an embodiment of this application is shown; Figure 9 This paper shows a structural block diagram of a simulation testing method apparatus according to an embodiment of this application; Figure 10 A structural block diagram of an electronic device proposed in this application is shown. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0013] In the accompanying drawings, the size of constituent elements, the thickness of layers, or areas may sometimes be exaggerated for clarity. Therefore, any implementation of this disclosure is not necessarily limited to the dimensions shown in the drawings, and the shapes and sizes of the components in the drawings do not reflect true proportions. Furthermore, the drawings schematically illustrate ideal examples, and any implementation of this disclosure is not limited to the shapes or values ​​shown in the drawings.

[0014] With the continuous development of automotive technology, data distribution services (DDS), as a communication middleware protocol, have been widely used for data interaction between the Electronic Data Capture (EDC) domain and the Vehicle Integration Unit (VIU) domain. However, in the actual development process of DDS services, the functional testing phase faces significant limitations. Specifically, EDC monolithic development relies heavily on EDC-related equipment, while functional testing after DDS service development typically requires the use of a test bench or prototype vehicle, leading to a high dependence on equipment resources. Furthermore, functional self-testing during development primarily focuses on the normal invocation and response of services, but other factors in a real test bench environment often interfere with the functional test results, resulting in low testing efficiency.

[0015] Therefore, in the embodiments of this application, the simulation testing method, apparatus, electronic device, and storage medium provided in this application, after receiving a user request and determining the service to be tested, determine a simulation control domain scenario and a target simulation service in the simulation control domain scenario based on the service to be tested. The simulation control domain scenario includes multiple simulation services, each representing a simulation service corresponding to a service deployed in the vehicle cockpit domain, and the target simulation service representing a simulation service corresponding to the service to be tested. Based on the service to be tested, an auxiliary service is configured in the simulation control domain scenario, the auxiliary service being a message middleware between the simulation control domain and the vehicle cockpit domain. Based on the auxiliary service and the target simulation service, simulation testing is performed on the service to be tested in the simulation control domain scenario.

[0016] In this application, the above-described method enables the determination of a simulation control domain scenario and a target simulation service within that scenario based on the service under test (SUPT). An auxiliary service is then configured within the simulation control domain scenario based on the SUPT, allowing for simulation testing of the SUPT within the simulation control domain scenario based on both the auxiliary service and the target simulation service. To achieve a complete test loop, an auxiliary service is configured within the simulation control domain scenario. This auxiliary service acts as a message middleware between the simulation control domain and the vehicle cockpit domain, ensuring uninterrupted communication and enabling comprehensive verification of the SUPT. This eliminates the need for a real test bench or test vehicle, allowing for simulation testing of the SUPT in the vehicle cockpit domain and significantly improving testing efficiency.

[0017] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0018] Body control domain: This can be represented by VIU. It is mainly responsible for the control and management of vehicle body-related functions, such as window control and headlight control.

[0019] Vehicle cabin area: This can be represented by EDC. It is mainly responsible for the control and management of related functions in the vehicle cabin, such as the central control screen display and air conditioning control.

[0020] Data distribution service: This can be represented by DDS, which is a communication middleware protocol used to realize data interaction between distributed systems. It can be used to realize data interaction between VIU and EDC, ensuring real-time, efficient and flexible data distribution.

[0021] The embodiments of this application will now be described with reference to the accompanying drawings.

[0022] Please see Figure 1 This application provides a simulation testing method applied to a simulation testing application tool. The method includes: S110: Receive user requests and determine the service to be tested.

[0023] Among them, the service to be tested can represent the service that needs to be tested among the services deployed in the vehicle cockpit domain.

[0024] One approach is to obtain the service name and functional parameters of the service after identifying it. The service name serves as a unique functional identifier for the service within the vehicle's cockpit domain, while the functional parameters represent the service's configuration information.

[0025] In this embodiment, a simulation testing application tool is provided to simulate and test the DDS service within the EDC. This tool offers a touch interface, allowing users to control the application and select the service to be tested. Furthermore, a VIU source code compilation system is configured within the simulation testing application tool. This system includes built-in compilation tools such as CMake, MinGW, and Python, enabling the compilation of VIU scenarios to obtain simulated VIU scenarios. The simulation testing application tool then connects the EDC and the simulated VIU, allowing for simulation testing of the DDS service within the EDC through the simulated VIU.

[0026] As an example, such as Figure 2 and Figure 3 As shown, where, Figure 2 This can be a communication diagram of EDC-VIU in a real-world scenario. Figure 3 This can be seen as a communication diagram between the EDC and the simulated VIU when the EDC and VIU are linked in the simulation test application tool mentioned above.

[0027] Specifically, such as Figure 2 As shown, when testing on a real test bench, the EDC can send services to the VIU via Ethernet, so that the VIU can send control signals to the real components on the vehicle to execute the corresponding services. After the real components on the vehicle execute the corresponding services, they can send processing signals to the VIU, so that the VIU can feed back the processing results to the EDC via Ethernet. Thus, the DDS service within the EDC can be tested based on the processing results.

[0028] Specifically, such as Figure 3 As shown, when the EDC end and the simulation VIU end are linked in the above simulation test application tool, when performing simulation tests on the DDS service within the EDC, the EDC end can send services to the simulation VIU end via Ethernet, so that the simulation VIU end can send analog control signals to the simulation service of the simulation VIU end, so that the simulation service can process the analog control signals and send analog processing signals to the simulation VIU end, so that the simulation VIU end can feed back the simulation processing results to the EDC end via Ethernet, thereby completing the simulation test of the DDS service within the EDC based on the simulation processing results.

[0029] S120: Determine the simulation control domain scenario and the target simulation service in the simulation control domain scenario based on the service to be tested.

[0030] The simulation control domain scenarios can include air conditioning thermal management simulation scenarios, vehicle body control simulation scenarios, and powertrain chassis simulation scenarios. In this application, the air conditioning thermal management simulation scenario can include functions such as air conditioning adjustment, seat ventilation, and seat heating. The vehicle body control simulation scenario can include control functions such as windows, doors, sunroof, seats, door handles, and wipers. The powertrain chassis simulation scenario can include functions such as chassis adjustment, suspension adjustment, charging and discharging, and readiness status.

[0031] The simulation control domain scenario may include multiple simulation services. The simulation service can represent the simulated service corresponding to the service deployed in the vehicle cockpit domain, and the target simulation service can represent the simulated service corresponding to the service to be tested.

[0032] As one approach, before performing simulation testing on the service under test, users can determine the corresponding simulation control domain scenario for the service under test on the touch interface based on the functional description of the service under test, and determine the target simulation service corresponding to the service under test in the simulation control domain scenario based on the functional parameters of the service under test on the touch interface.

[0033] As another approach, before performing simulation testing on the service under test, the simulation control domain scenario corresponding to the service under test can be determined based on the intelligent matching process within the simulation testing application tool, and the target simulation service corresponding to the service under test within the simulation control domain scenario can be further determined.

[0034] Optionally, the intelligent matching process may include: Before acquiring the service under test, multiple matching rules can be pre-established in the simulation testing application tool. These rules may include precise matching rules for service names, fuzzy matching rules for functional parameter types, and service quality compatibility matching rules. This allows for the parsing of the service's metadata after acquisition, including but not limited to functional parameter information such as service name, interface ID, and version number, to construct a complete feature description model of the service under test. Subsequently, a three-level progressive matching engine can be used for intelligent matching. The first level can perform rapid retrieval based on functional parameter hash values ​​to filter out a set of candidate simulation control domain scenarios. The second level can calculate similarity using a parameter pattern matching algorithm to filter out a subset of simulation control domain scenarios with matching scores exceeding a threshold. The third level can combine service quality strategy compatibility analysis, including dimensions such as reliability level, transmission priority, and timeliness requirements, to determine the optimal matching simulation control domain scenario using a weighted scoring algorithm. Then, in the target simulation service determination phase, the service relationship graph of the simulation control domain scenario is loaded. Based on service call dependencies, data flow transformation rules, and exception handling logic, a test service topology containing the main service node and related service nodes is automatically generated. This allows the target simulation service of the service under test within the simulation control domain scenario to be determined. This improves matching efficiency, reduces the workload for users, and makes it easier for users to use.

[0035] S130: Based on the service to be tested, configure auxiliary services within the simulation control domain scenario.

[0036] The auxiliary service can be a message middleware between the simulation control domain and the vehicle cockpit domain. The auxiliary service can include a listening service and a response service. In this application, the listening service can be a DDS service on the simulation control domain side, used to listen to and receive signals sent by the service under test. The response service can be a DDS service on the simulation control domain side, used to respond to the listened-to signals.

[0037] One approach is to customize the VIU services that need to be listened to and responded to based on user requests. In other words, users can specify specific VIU services and their functional parameters through the simulation test's touch interface or configuration file. This allows the simulation test application to generate corresponding listening and response services based on the relevant information, enabling the simulation test to flexibly adapt to different testing needs and improve the relevance and efficiency of the test. As an example, a user can specify to listen to a specific temperature control request signal and configure the response service to return a corresponding temperature adjustment confirmation signal upon receiving the signal.

[0038] As one approach, a mapping relationship can be established between the service under test, the monitoring service, the response service, and the target simulation service based on the service under test, so as to configure auxiliary services within the simulation control domain scenario.

[0039] Optionally, based on the service under test, the functional parameters of the service under test can be obtained and configured in the listening service so that the listening service can listen for request signals that match the service under test; or based on the target simulation service, the functional parameters of the target simulation service can be obtained and configured in the response service so that the response service can respond to the request signal.

[0040] The request signal can be a command related to the service under test sent from the vehicle cockpit domain to the simulation control domain, such as a temperature adjustment request or a seat position adjustment request.

[0041] In existing methods, service signals between the EDC (Electronic Data Center) and VIU (Visible Unit) terminals often maintain a one-to-one correspondence, making it difficult to handle non-directly corresponding signals. This results in insufficient testing flexibility and an inability to comprehensively cover various types of signal verification, leading to low test coverage. However, in this embodiment, the service under test, the monitoring service, the response service, and the target simulation service are associated. By customizing the VIU services that need to be monitored and responded to, a flexible mapping relationship between services is established. Furthermore, a custom parameter rule setting function is introduced, which can accurately transform abstract instructions (such as increasing air conditioning fan speed) into specific instructions that can be executed by the VIU terminal. This effectively simulates the implementation of related functions, greatly expanding the scope of testing and further improving the comprehensiveness and efficiency of testing.

[0042] like Figure 4 As shown, a mapping relationship can be established between the service under test, the monitoring service, the response service, and the target simulation service to build a communication link. Specifically, the service under test can be determined in the vehicle cockpit domain. Based on the functional parameters of the service under test, the monitoring service's service, method, and port can be configured in the simulation control domain scenario, and corresponding monitoring parameters can be set. Furthermore, the monitoring service can continuously monitor in the background to listen for request signals that match the service under test. The target simulation service can be determined in the simulation control domain scenario based on the service under test. Based on the functional parameters of the target simulation service, the response service's service, method, and port can be configured, and corresponding parameter rules and response parameters can be pre-set so that the response service responds to request signals, thereby ensuring the testing efficiency of the service under test.

[0043] S140: Based on the auxiliary service and the target simulation service, perform simulation testing on the service under test in the simulation control domain scenario.

[0044] In one approach, after the listening service detects a request signal from the vehicle cockpit domain, it can send the request signal to the target simulation service for simulation processing to obtain the processing result, and then return the processing result to the vehicle cockpit domain based on the response service.

[0045] The request signal can be the content of a request issued by the vehicle cockpit domain based on the service under test.

[0046] Optionally, when performing simulation testing on the service under test, the target simulation service can be run in the simulation testing application tool, and the request signal sent by the vehicle cockpit domain can be listened to based on the listening service. When the listening service hears the request signal sent from the vehicle cockpit domain, it can send the request signal to the target simulation service for simulation processing to obtain the processing result, and return the processing result to the vehicle cockpit domain based on the response service to complete the simulation service of the service under test.

[0047] As one approach, request signals corresponding to the service under test can be periodically obtained based on user requests. After the simulation service performs simulation processing, the processing results can be periodically returned based on the response service. The debug log window prints the request signals and the result logs corresponding to the processing results in real time and saves the result logs locally.

[0048] In this embodiment, the monitoring service can run continuously in the background without manual intervention. Users can continuously send service requests from the EDC (Electronic Data Center) and complete development and testing by collecting and analyzing the returned log results. This simplifies the test environment setup process, reduces reliance on hardware resources, and significantly improves work efficiency, making EDC monolithic development and testing more efficient and convenient. Furthermore, service testing in related methods typically involves pre-setting the number of tests and test intervals, and terminating the process upon completion. In this application, services that need to be monitored and responded to can run continuously in the background according to the user's pre-configured settings, and the monitoring service result logs can be output in real time, thus providing users with a continuous and real-time service monitoring and testing experience.

[0049] As a method, to accommodate developers' usage habits and meet their needs, a CSV file (Comma-Separated Values) can be provided for each simulation control domain scenario. The CSV file can be a common text file format used to store tabular data. In this application, the CSV file can record detailed service information related to the listening and response services. Users can efficiently manage this information using specialized tools, or directly open the CSV file with common editing software such as Excel for intuitive viewing and editing of its contents, thereby significantly improving the efficiency of service content management.

[0050] In this embodiment, a VIU simulation testing environment is constructed, enabling developers to complete the entire development and testing process without relying on a physical VIU bench. This solution effectively addresses pain points such as limited hardware resources and complex test environment setup, supporting rapid verification of prototype functions during the development phase and compatibility verification across multiple vehicle models and versions during the testing phase, significantly improving development efficiency and test coverage. Specifically, in the initial design phase of EDC monolithic development, developers can utilize VIU simulation testing to quickly build a virtual VIU environment for prototype verification and functional testing. Furthermore, by simulating different vehicle models and versions of VIU, design issues can be identified early, avoiding major modifications in subsequent development. During integration testing between the EDC and VIU, a real vehicle interface environment can be simulated, ensuring the EDC can perform single or multiple functions, synchronous or asynchronous functional testing. Simultaneously, by simulating different vehicle models and versions of VIU, the compatibility and scalability of the EDC monolithic system can also be verified. In practical applications, VIU simulation testing customizes parameters and configurations according to the EDC's design requirements, executes service functions by receiving data and instructions sent by the EDC, and returns results, greatly improving testing efficiency and flexibility. Developers can begin testing immediately without waiting for the real-world environment to be ready, and real-time result logs help quickly locate and resolve issues. This reduces testing costs and saves on equipment and personnel deployment costs. Its customizability and scalability further enhance the flexibility and accuracy of simulation testing.

[0051] This embodiment provides a simulation testing method that, through the aforementioned approach, determines the simulation control domain scenario and the target simulation service within the simulation control domain scenario based on the service under test (SUPT). Then, auxiliary services are configured within the simulation control domain scenario based on the SUPT, allowing for simulation testing of the SUPT within the simulation control domain scenario based on both the auxiliary services and the target simulation service. To achieve a complete test loop, auxiliary services are configured within the simulation control domain scenario. These auxiliary services act as message middleware between the simulation control domain and the vehicle cockpit domain, ensuring uninterrupted communication and enabling comprehensive verification of the SUPT. This eliminates the need for a real test bench or test vehicle to complete the simulation testing of the SUPT in the vehicle cockpit domain, significantly improving testing efficiency.

[0052] Please see Figure 5 This application provides a simulation testing method, the method comprising: S210: Obtain the control domain source code, and set the storage path, file name, and required number of threads for the control domain source code.

[0053] Among them, the control domain source code can be the source code used to implement the body control domain function, and can be used to implement control functions and service interfaces.

[0054] One approach is to configure the corresponding control domain source code in a local environment, specify the storage path of the control domain source code, and customize the name of the executable file through a pre-defined tool interface. Furthermore, users can select the number of threads used when compiling the source code based on system performance and requirements to optimize compilation efficiency. In this application, the pre-defined tool may include, but is not limited to, compilation tools such as CMake, MinGW, and Python.

[0055] In this embodiment, users can choose the number of threads to use according to their own needs, so as to flexibly balance compilation performance and resource consumption by adjusting the number of threads. Specifically, for projects that need to be compiled quickly, users can choose to use more threads to improve compilation speed; while for resource-limited environments, users can choose to use fewer threads to reduce resource consumption, thereby achieving efficient resource utilization.

[0056] In this embodiment, the VIU source code compilation system can compile the control domain source code based on the user-preset control domain source code, the user-preset file name, and the number of threads selected by the user to obtain a simulation control domain executable file.

[0057] S220: Based on the control domain source code, obtain all control domain service methods, parameter information, and control domain service interface source code in the control domain source code.

[0058] As one approach, the VIU source code compilation system can automatically parse the control domain source code, extract and generate corresponding control domain service methods and parameter information, and generate the corresponding control domain service interface source code. Afterwards, all the obtained control domain service methods, parameter information, and control domain service interface source code can be saved to a directory defined by the compilation tool. The parameter information can be an XML file. In this application, the XML file can describe the service interface and parameter information in detail, making service integration and invocation simple and clear, and providing data support for service selection in VIU service simulation.

[0059] In this embodiment, the VIU source code compilation system can quickly generate service interface files for simulation testing by automatically parsing and extracting key information from the source code, providing a foundation for subsequent compilation and testing, improving development efficiency and ensuring the accuracy of the interface.

[0060] S230: Based on all control domain service methods, parameter information, and control domain service interface source code in the control domain source code, a configuration file is obtained. The control domain source code is then compiled based on the configuration file to obtain a simulation control domain executable file.

[0061] In this embodiment, the configuration file can be a CMakeLists file. Specifically, the VIU source code compilation system can construct a configuration file based on all control domain service methods, parameter information, and control domain service interface source code in the control domain source code, in order to compile the control domain source code and obtain the simulation control domain executable file.

[0062] As a method, during the compilation of the control domain source code, the compilation tool's log interface will update in real time, displaying the compilation progress and detailed information. If any problems occur during compilation, the log information printed in the interface can be used to quickly locate and troubleshoot the issues. When the compilation progress reaches 100%, it indicates that the source code compilation has been successfully completed. At this point, a simulation control domain executable file will be generated in the directory specified by the compilation tool. This simulation control domain executable file can be directly used for simulation debugging of the VIU service.

[0063] In the embodiments of this application, such as Figure 6 As shown, there are two compilation methods within the simulation testing application tool. One is regular compilation, which, specifically, generates corresponding client or server executable files based on the respective compilation scripts and source code for the client or server. The other is VIU simulation compilation, which, specifically, generates the corresponding control domain executable file based on the control domain source code and the corresponding compilation script.

[0064] S240: Based on the configuration file and the simulation control domain execution file, the simulation control domain scenario is obtained.

[0065] One approach is to configure a simulation control domain scenario based on the service methods and parameter information in the configuration file selected by the user. In this application, the simulation control domain scenario obtained based on user needs can be stored in the simulation test application tool as a user-defined scenario or a backup scenario for future use.

[0066] As another approach, the corresponding simulation control domain executable file can be executed based on the configuration file and the simulation control domain executable file to simulate the service methods within the simulation control domain scenario, thereby obtaining the simulation control domain scenario.

[0067] In this embodiment, multiple simulation control domain scenarios can be configured within the simulation testing application tool, such as an air conditioning thermal management simulation scenario, a vehicle body control simulation scenario, and a powertrain chassis simulation scenario. Furthermore, if the simulation testing application tool does not contain the simulation control domain scenario required by the user, the VIU source code compilation system can generate the corresponding simulation control domain scenario based on the control domain source code. This greatly enriches the application scope of simulation testing, improves the flexibility and adaptability of testing, and meets the testing needs of different users in various scenarios.

[0068] S250: Receives user requests and determines the service to be tested.

[0069] S260: Determine the simulation control domain scenario and the target simulation service in the simulation control domain scenario based on the service to be tested.

[0070] S270: Based on the service to be tested, configure auxiliary services within the simulation control domain scenario.

[0071] S280: Based on the auxiliary service and the target simulation service, perform simulation testing on the service under test in the simulation control domain scenario.

[0072] This embodiment provides a simulation testing method that, through the aforementioned approach, determines a simulation control domain scenario and a target simulation service within the simulation control domain scenario based on the service under test (SUPT). Then, auxiliary services are configured within the simulation control domain scenario based on the SUPT, allowing simulation testing of the SUPT within the simulation control domain scenario based on both the auxiliary services and the target simulation service. To achieve a complete test loop, auxiliary services are configured within the simulation control domain scenario. These services act as message middleware between the simulation control domain and the vehicle cockpit domain, ensuring uninterrupted communication and enabling comprehensive verification of the SUPT. This eliminates the need for a real test bench or test vehicle to complete the simulation testing of the SUPT in the vehicle cockpit domain, significantly improving testing efficiency. Furthermore, this application allows for the configuration of multiple simulation control domain scenarios within the simulation testing application tool, such as an air conditioning thermal management simulation scenario, a body control simulation scenario, and a powertrain chassis simulation scenario. Furthermore, if the simulation testing application tool does not include the simulation control domain scenario required by the user, the VIU source code compilation system can generate the corresponding simulation control domain scenario based on the control domain source code, thereby greatly enriching the application scope of simulation testing, improving the flexibility and adaptability of testing, and meeting the testing needs of different users in various scenarios.

[0073] To better understand the solutions of all embodiments of this application, the following is based on... Figure 7 and Figure 8 This paper introduces the basic business process of a vehicle body control domain simulation method according to this application. Among other things, Figure 7 It can be a flowchart of a source code compilation method. Figure 8 This can be a flowchart of a simulation testing method. Please see Figure 7 The process can proceed as follows: Step S1 involves obtaining the control domain source code and setting its storage path and file name; Step S2 involves determining the number of threads required for the current compilation process; Step S3 involves obtaining all control domain service methods, parameter information, and control domain service interface source code from the control domain source code; Step S4 involves obtaining a configuration file based on all control domain service methods, parameter information, and control domain service interface source code; Step S5 involves compiling the control domain source code based on the configuration file to obtain the simulation control domain executable file; and finally, Step S6 involves obtaining the simulation control domain scenario based on the configuration file and the simulation control domain executable file.

[0074] Please participate Figure 8 Based on step S1, the service to be tested can be determined. Based on step S2, it can be determined whether a simulation control domain scenario needs to be added to the simulation test application tool. If it needs to be added, a simulation control domain executable file can be generated based on the control domain source code in step S3. Based on the configuration file and the simulation control domain executable file, a simulation control domain scenario can be obtained. If it does not need to be added, a simulation control domain scenario can be determined based on the service to be tested in step S4. Based on step S5, the target simulation service in the simulation control domain scenario can be determined based on the service to be tested. Based on step S6, a listening service can be configured based on the service to be tested. Based on step S7, a response service can be configured based on the target simulation service. Based on step S8, it can be selected whether to generate real-time result logs during the compilation process. After the above preparation stage is completed, a simulation test of the DDS service of EDC can be started in step S9. The simulation test can be closed in step S11.

[0075] Please see Figure 9 This application provides a vehicle body control domain simulation device 600, the device 600 comprising: The simulation test preparation unit 610 is used to receive user requests to determine the service to be tested, wherein the service to be tested represents the service that needs to be tested among the services deployed in the vehicle cockpit domain; based on the service to be tested, determine a simulation control domain scenario and a target simulation service in the simulation control domain scenario, wherein the simulation control domain scenario includes multiple simulation services, wherein the simulation service represents the simulation service corresponding to the service deployed in the vehicle cockpit domain, and the target simulation service represents the simulation service corresponding to the service to be tested; based on the service to be tested, configure an auxiliary service in the simulation control domain scenario, wherein the auxiliary service is a message middleware between the simulation control domain and the vehicle cockpit domain.

[0076] The simulation test execution unit 620 is used to perform simulation tests on the service under test in the simulation control domain scenario based on the auxiliary service and the target simulation service.

[0077] In one approach, the simulation test preparation unit 610 is specifically used to establish a mapping relationship between the service under test, the monitoring service, the response service, and the target simulation service based on the service under test, so as to configure auxiliary services within the simulation control domain scenario.

[0078] Optionally, the simulation test preparation unit 610 is specifically used to: obtain the functional parameters of the service under test based on the service under test; configure the functional parameters of the service under test in a listening service so that the listening service listens for request signals that match the service under test; and obtain the functional parameters of the target simulation service based on the target simulation service; configure the functional parameters of the target simulation service in a response service so that the response service responds to the request signals.

[0079] In one manner, the simulation test execution unit 620 is specifically used to send the request signal to the target simulation service for simulation processing after the listening service detects the request signal sent from the vehicle cockpit domain, so as to obtain the processing result, and return the processing result to the vehicle cockpit domain based on the response service, wherein the request signal is the request content issued by the vehicle cockpit domain based on the service under test.

[0080] Optionally, the simulation test execution unit 620 is specifically used to periodically obtain the request signal corresponding to the service under test based on the user request, and after the simulation service performs simulation processing, periodically return the processing result based on the response service; the debug log window prints the result log corresponding to the request signal and the processing result in real time, and saves the result log to the local machine.

[0081] In one approach, the simulation test preparation unit 610 is specifically used to obtain the control domain source code and set the storage path, file name, and required number of threads for the control domain source code; based on the control domain source code, it obtains all control domain service methods, parameter information, and control domain service interface source code in the control domain source code; based on all control domain service methods, parameter information, and control domain service interface source code in the control domain source code, it obtains a configuration file; based on the configuration file, it compiles the control domain source code to obtain a simulation control domain executable file; based on the configuration file and the simulation control domain executable file, it obtains a simulation control domain scenario.

[0082] The following will combine Figure 10 This application describes an electronic device.

[0083] Please see Figure 10Based on the above-described vehicle body control domain simulation method and apparatus, this application embodiment also provides another electronic device 100 capable of executing the aforementioned vehicle body control domain simulation method. The vehicle 100 includes a processor 102, a memory 104, and a communication module 106. The memory 104 stores a program capable of executing the contents of the aforementioned embodiments, and the processor 102 can execute the program stored in the memory 104.

[0084] The processor 102 may include one or more processing cores. The processor 102 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data of the electronic device 100 by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling data stored in the memory 104. Optionally, the processor 102 may be implemented using at least one of the following hardware forms: a Neural Network Processing Unit (NPU), a Digital Signal Processing Unit (DSP), a Field-Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA). The processor 102 may integrate one or more of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Neural Network Processing Unit (NPU), and a modem. Specifically, the CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; the NPU handles multimedia data such as video and images; and the modem handles wireless communication. It is understandable that the aforementioned modem may not be integrated into the processor 102, but may be implemented using a separate communication chip.

[0085] The memory 104 may include random access memory (RAM), read-only memory (ROM), and double data rate synchronous dynamic random access memory (DDR). The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the electronic device 100 during use (such as phonebook data, audio and video data, chat log data, etc.).

[0086] The communication module 106 can be used to realize information interaction between the electronic device 100 and other devices, such as transmitting device control commands, manipulation request commands, and status information acquisition commands. When the other devices are different devices, their corresponding communication modules 106 may be different.

[0087] This application provides a computer-readable storage medium. The computer-readable storage medium stores program code that can be called by a processor to execute the methods described in the above method embodiments.

[0088] Computer-readable storage media can be electronic storage devices such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, computer-readable storage media include non-transitory computer-readable storage media. The computer-readable storage medium has storage space for program code that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code can be compressed, for example, in a suitable form.

[0089] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0090] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0091] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0092] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0093] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0094] The simulation testing method, apparatus, and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A simulation testing method, characterized in that, The method includes: Receive user requests and determine the services to be tested. The services to be tested represent the services deployed in the vehicle cockpit domain that need to be tested. Based on the service under test, a simulation control domain scenario and a target simulation service in the simulation control domain scenario are determined. The simulation control domain scenario includes multiple simulation services. The simulation service represents the simulation service corresponding to the service deployed in the vehicle cockpit domain. The target simulation service represents the simulation service corresponding to the service under test. Based on the service to be tested, an auxiliary service is configured in the simulation control domain scenario. The auxiliary service is a message middleware between the simulation control domain and the vehicle cockpit domain. The auxiliary service includes a listening service and a response service. Based on the auxiliary service and the target simulation service, the service under test is simulated and tested in the simulation control domain scenario; The configuration of auxiliary services within the simulation control domain scenario based on the service under test includes: Based on the service under test, obtain the functional parameters of the service under test, and configure the functional parameters of the service under test in the listening service so that the listening service listens for request signals that match the service under test; Based on the target simulation service, the functional parameters of the target simulation service are obtained, and the functional parameters of the target simulation service are configured in the response service so that the response service responds to the request signal.

2. The method according to claim 1, wherein configuring auxiliary services within the simulation control domain scenario based on the service under test includes: Based on the service under test, a mapping relationship is established between the service under test, the monitoring service, the response service, and the target simulation service to configure auxiliary services within the simulation control domain scenario.

3. The method according to claim 1, characterized in that, The simulation test of the service under test in the simulation control domain scenario includes: After the listening service detects a request signal sent from the vehicle cockpit domain, it sends the request signal to the target simulation service for simulation processing to obtain a processing result, and returns the processing result to the vehicle cockpit domain based on the response service. The request signal is the request content issued by the vehicle cockpit domain based on the service under test.

4. The method according to claim 3, characterized in that, The method further includes: Based on user requests, the system periodically acquires request signals corresponding to the service under test. After the simulation service performs simulation processing, it periodically returns processing results based on the response service. The debug log window prints the request signal and the result log corresponding to the processing result in real time, and saves the result log to the local machine.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Obtain the control domain source code, and set the storage path, file name, and required number of threads for the control domain source code; Based on the control domain source code, obtain all control domain service methods, parameter information, and control domain service interface source code in the control domain source code; Based on all control domain service methods, parameter information, and control domain service interface source code in the control domain source code, a configuration file is obtained. The control domain source code is then compiled based on the configuration file to obtain a simulation control domain executable file. Based on the configuration file and the simulation control domain execution file, the simulation control domain scenario is obtained.

6. The method according to claim 1, characterized in that, The simulation control domain scenarios include air conditioning thermal management simulation scenario, vehicle body control simulation scenario, and powertrain chassis simulation scenario.

7. A vehicle body control domain simulation device, characterized in that, The device includes: A simulation test preparation unit is used to receive user requests to determine the service to be tested, wherein the service to be tested represents the service that needs to be tested among the services deployed in the vehicle cockpit domain; based on the service to be tested, determine a simulation control domain scenario and a target simulation service in the simulation control domain scenario, wherein the simulation control domain scenario includes multiple simulation services, wherein the simulation service represents the simulation service corresponding to the service deployed in the vehicle cockpit domain, and the target simulation service represents the simulation service corresponding to the service to be tested; based on the service to be tested, configure auxiliary services in the simulation control domain scenario, wherein the auxiliary services are message middleware between the simulation control domain and the vehicle cockpit domain; the auxiliary services include a listening service and a response service. The simulation test execution unit is used to perform simulation tests on the service under test in the simulation control domain scenario based on the auxiliary service and the target simulation service. The simulation test preparation unit is specifically used to obtain the functional parameters of the service under test based on the service under test, configure the functional parameters of the service under test in the listening service, so that the listening service listens for request signals that match the service under test; and obtain the functional parameters of the target simulation service based on the target simulation service, configure the functional parameters of the target simulation service in the response service, so that the response service responds to the request signal.

8. An electronic device, characterized in that, Includes one or more processors and memory; One or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs being configured to perform the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code, wherein the method described in any one of claims 1-6 is executed when the program code is run.

Images