Domain controller testing method, system and central multi-domain testing platform, method

Abstract

The application relates to a domain controller test method and system, a central multi-domain test platform and method, and belongs to the technical field of automobile electronic testing. The hardware modules of a scanning domain controller are modularized to read local configuration operation and test item configuration operation, so that the block program has stronger portability, development work is greatly reduced, personalized self-defined configuration can realize DV test in different states, and more comprehensive test function selection is provided. The domain controller test system provided by the application can replace the running of application software in the automobile domain controller, realize the prior development of the hardware platform of the domain controller and DV test verification, solve the problem that DV test cannot be performed in the state that no application software or the application software is not developed, guarantee test verification in the development stage, cover a wide hardware test range, support more test items, reduce the development burden, and accelerate the process of putting the automobile domain controller into application.

Description

Technical Field

[0001] This invention relates to the technical field of automotive electronic testing, and more specifically, to a domain controller testing method, system, and central multi-domain testing platform and method. Background Technology

[0002] SoC, also known as system-on-a-chip, integrates multiple functional modules on a single chip, such as CPU, GPU, memory, audio processor, etc. With the development of smart cars, there are more and more car controllers based on SoC as the main chip.

[0003] During the automotive design and testing phase, test engineers need to consider whether the various software and hardware installed on the vehicle meet the various testing requirements of the entire vehicle. At this time, DV testing comes into being. DV testing stands for Design Validation Test, which can be a design verification test for hand-made parts or molded parts.

[0004] Traditional automotive controller development involves completing both the hardware and software development before performing digital vehicle (DV) testing. Because automotive application software and the hardware of the computing domain are coupled, DV testing is impossible without application software (if the software is not yet developed or is incomplete). Furthermore, with the increasing complexity of automotive software, and the possibility of software updates or feature development occurring after vehicle sales via remote over-the-air (OTA) upgrades, the traditional development model, which requires completing both hardware and software development before conducting various tests and verifications, slows down the current development process and prolongs the time before the controller is deployed to applications. In addition, different hardware platforms and hardware states require different DV testing software, resulting in a heavy development workload. Summary of the Invention

[0005] One objective of this invention is to provide a domain controller testing method that solves the problem that DV testing cannot be performed when the automotive domain controller lacks application software or the application software is not yet developed, thus slowing down the automotive controller development process and increasing the time before the automotive controller is put into application. It also addresses the issue of requiring different DV test software for different hardware platforms and hardware states, resulting in a heavy development workload. A second objective is to provide a domain controller testing system. A third objective is to provide a central multi-domain testing platform that ensures simultaneous DV testing of multiple domain controllers under a centralized architecture without interference. A fourth objective is to provide a central multi-domain testing method that solves the problem of low DV testing efficiency.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A domain controller testing method, the testing method comprising:

[0008] The first test module sends the start test command, test items, and test configuration to the second test module;

[0009] The second test module calls the domain controller under test to start the simulation test according to the start test command, test items and test configuration, and the second test module and the third test module conduct data communication test.

[0010] The second test module transmits the simulation test results and data communication test results to the first test module, which then analyzes and verifies the simulation test results and data communication test results.

[0011] Furthermore, before the first test module sends the start test command, test items, and test configuration to the second test module, the test method further includes: the second test module scanning the hardware modules it supports and reading the local configuration; after the first test module initiates a connection, the second test module sends the test list of the domain controllers to be tested to the first test module; the first test module matches the hardware module test configuration stored locally with the test list of the domain controllers to be tested sent by the second test module, displays the test items and test indicators to the user, and then the user customizes the test configuration.

[0012] Furthermore, the domain controller test includes communication, audio playback, video display, and / or load testing. For the communication section, data transmission and reception between different SoC hardware platforms are performed at a set range of communication transmission rates, and data transmission and reception verification is conducted to simulate the domain controller's communication transmission conditions. For the audio playback section of the automotive domain controller, audio data is played to simulate the sound playback conditions of an automotive domain controller in a real-world application scenario. For the video display section, patterns and rendered graphics are simulated, and the frame rate is set to output to the video output port. The domain controller's video acquisition board collects the video output data of the domain controller and performs video output data verification to simulate the image processing and display call conditions in the domain controller. For the load testing section, the operation of different hardware modules under different loads is simulated to simulate the actual operation of the domain controller.

[0013] Based on the aforementioned technical methods, the operations of scanning supported hardware modules, reading local configurations, and configuring test items are performed in a distributed and modular manner. This modular approach enhances the portability of the program and significantly reduces development work. Furthermore, personalized custom configurations enable DV testing under different conditions, providing a more comprehensive selection of testing functions. By using an automotive domain controller testing system to replace application software running within the automotive domain controller, the hardware platform of the automotive domain controller can be developed first and then subjected to DV testing verification. This solves the problem of being unable to conduct DV testing when there is no application software or the application software is not yet fully developed, without affecting the testing and verification of the domain controller during the development phase, thus accelerating the process of deploying the automotive domain controller to applications.

[0014] Furthermore, the second test module runs on different systems on the domain controller under test.

[0015] Furthermore, the different systems on the domain controller under test include: Linux system, Android system, or QNX system.

[0016] Based on the above technical means, the same set of code is used for DV testing on different SoC hardware platforms, different hardware modules, and different system architectures. This reduces the investment in development work, avoids the situation where DV testing cannot be carried out in the early stages of product development, enables DV testing to have a standard testing process, and improves the efficiency of DV testing.

[0017] Furthermore, the test items for data communication experiments conducted by the second and third test modules include: network throughput, packet loss rate, latency, and jitter.

[0018] A domain controller testing system, the system comprising:

[0019] The first test module, the second test module, and the third test module;

[0020] The first test module runs on the host platform and connects to the second test module via a network.

[0021] The second test module runs on the domain controller under test, and communicates with the third test module through a communication interface;

[0022] The third test module runs on the data communication test platform.

[0023] Based on the above technical means, the entire domain controller testing system includes a first test module, a second test module, and a third test module that run in a distributed manner on different platforms and are interconnected and cooperate with each other. Based on the cooperation of the first test module, the second test module, and the third test module, a simple and convenient testing mode is realized.

[0024] Furthermore, the network is a LAN or WLAN network.

[0025] Based on the above technical means, the first test module is connected to the second test module through a LAN or WLAN network, which can meet the testing and analysis requirements of high-bandwidth hardware modules and further ensure that the first test module outputs data streams to the second test module for effective analysis.

[0026] Furthermore, the second test module, based on the general test standard, receives information sent by the first test module, calls the domain controller under test to start the simulation test, and conducts a data communication test with the third test module, transmitting the simulation test results and data communication test results to the first test module.

[0027] Furthermore, the information sent by the first test module includes sending a start test command, test items, and test configuration.

[0028] Based on the aforementioned technical means, the test items and test configurations are clearly defined in the first test module. When changing the platform under test, only a portion of the program needs to be ported for normal operation. Furthermore, the second test module, leveraging universal testing standards, enables testing using the same code across different SoC hardware platforms, hardware modules, and system architectures. This reduces development effort and solves the problem of developing different DV test software platforms for different hardware platforms and states. It also enhances the portability of the entire testing method, covers a wider range of hardware tests, supports more test items, and reduces the development burden. The second test module, based on the start test command, test items, and test configuration, invokes the domain controller under test to initiate simulated testing, simulating the application software's operation on the computing domain controller. The cooperation of the first, second, and third test modules provides a more comprehensive selection of test functions, enabling priority development and DV test verification of the automotive domain controller platform. Even without application software or with incomplete application software development, the test verification of the automotive domain controller during the development phase is not affected, optimizing the DV test process and the time required for the automotive controller to be deployed to applications.

[0029] Furthermore, the first test module is equipped with an application front-end and a general test framework. The general test framework is used to analyze and verify the simulation test results and data communication test results. The application front-end is used to provide test module selection, custom test items, application state simulation, display analysis and verification result data, and output test reports.

[0030] The second test module is equipped with a test service program and the POSIX API general test standard required for writing the test service program. The second test module communicates with the general test framework of the first test module through a LAN / WLAN network. The third test module is equipped with a communication interface test program.

[0031] Furthermore, the first test module also includes a database section for storing test items, test metrics, and user-defined test configurations for different SoC hardware platforms and different hardware modules on the domain controller under test.

[0032] A central multi-domain test platform includes several domain controllers, each domain controller having at least one SoC hardware platform, and the SoC hardware platforms are connected to each other via Ethernet and communication interfaces.

[0033] Each SoC hardware platform runs a second test module. At the same time, multiple first test module processes are started on the host platform. Each first test module connects to the second test modules running on different SoC hardware platforms. A third test module runs on the data communication test platform. Each second test module communicates with the third test module through a communication interface to conduct data communication tests.

[0034] Based on the above technical means, the second test module is run on different SoC hardware platforms, and multiple first test module processes are started on the host platform to connect the second test modules on different SoC hardware platforms. This ensures that the tests between SoC hardware platforms do not affect each other and that the tests can be performed simultaneously, thereby improving the accuracy of application simulation.

[0035] Furthermore, the central multi-domain test platform also includes a communication unit. The plurality of domain controllers include a driving domain controller and a cockpit domain controller. The driving domain controller is connected to the cockpit domain controller, and the driving domain controller and the cockpit domain controller are also connected to the communication unit respectively.

[0036] Furthermore, the driving domain controller includes a driving domain SoC module, a first MCU module, a second MCU module, a first autonomous driving SoC module, a second autonomous driving SoC module, a panoramic camera, a first front-view camera, a rear-view camera, a surround-view camera, and a second front-view camera. The first autonomous driving SoC module is associated with the panoramic camera and the first front-view camera, and the second autonomous driving SoC module is associated with the rear-view camera, the surround-view camera, and the second front-view camera. The first autonomous driving SoC module is connected to the first MCU module and the second MCU module, respectively, and the second autonomous driving SoC module is connected to the first MCU module and the second MCU module, respectively. The cockpit domain controller includes a cockpit domain SoC module, an instrument panel, an AR-HUD augmented reality head-up display, a central control screen, a passenger screen, and an audio module. The cockpit domain SoC module is associated with the instrument panel, the AR-HUD augmented reality head-up display, the central control screen, the passenger screen, and the audio module.

[0037] The cockpit domain SoC module is connected to the driver domain SoC module;

[0038] The communication unit includes a first Ethernet Switch module, a second Ethernet Switch module, and a 4G module; the first autonomous driving SoC module is connected to the second autonomous driving SoC module, the first autonomous driving SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively, and the second autonomous driving SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively; the cockpit domain SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively, the driving domain SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively, and the first Ethernet Switch module is connected to the 4G module.

[0039] Furthermore, the SoC hardware platform is equipped with several hardware modules to be tested. Each hardware module to be tested consists of three parts. The first part of the hardware module to be tested is tested by the SoC hardware platform itself. The second part of the hardware module to be tested completes data communication experiments by connecting with the third test module. The third part of the hardware module to be tested is connected to the first test module. The first test module receives the data stream output by the third part of the hardware module to be tested based on the SoC hardware platform and performs analysis and verification.

[0040] Furthermore, the first test module sends a start test command, test items, and test configuration to the second test module; the second test module, based on a general test standard, calls the domain controller under test to start a simulation test according to the start test command, test items, and test configuration, and the second test module and the third test module conduct a data communication test; the second test module transmits the simulation test results and data communication test results to the first test module, and the first test module analyzes and verifies the simulation test results and data communication test results.

[0041] Furthermore, several domain controllers are integrated to form a central architecture. The central architecture is connected to the 4G module or TBOX controller via an Ethernet switch module to enable Internet access to the backend server. When conducting data communication tests on Internet access capabilities, the third test module is run on the backend server and connected to the 4G module or TBOX controller to conduct data communication tests on Internet access capabilities.

[0042] Based on the aforementioned technical means, the third test module runs on a backend server that differs from the centralized architecture, thus separating the test platform for data communication experiments from that for other tests.

[0043] A central multi-domain testing method, used for testing multiple domain controllers in a central multi-domain testing platform, includes:

[0044] Configure several SoC hardware platforms on the same local area network;

[0045] The second test module is deployed to each SoC hardware platform and a third test module is deployed to the communication interface to be tested on each SoC hardware platform, and the third test module is run on the data communication test platform associated with the second test module.

[0046] Start multiple first test module processes matching the number of SoC hardware platforms under test, and establish connections between each individual process of the first test module and different second test modules;

[0047] The first test module displays the hardware devices, test items, and test configurations supported by the corresponding SoC hardware platform under test. Select the hardware module to be tested and choose different levels of simulation.

[0048] Start the synchronous test command, and each first test module process will send the test items and test configurations to its respective connected second test module;

[0049] The second test module calls the domain controller under test to start a simulation test, and outputs the data stream to be analyzed and the test results to the first test module for analysis and verification.

[0050] Based on the aforementioned technical methods, when testing and verifying multiple domain controllers, a second test module is deployed and run on different SoC hardware platforms, and a third test module is deployed for the communication interface under test of each SoC hardware platform. Multiple first test module processes are started on Windows to connect to the second test modules on different SoC hardware platforms, ensuring that testing between SoC hardware platforms does not interfere with each other and that testing can be performed simultaneously, thus improving the accuracy of application simulation. By employing the cooperation of the first, second, and third test modules, different levels of application software simulation are selected to invoke the hardware operation of the domain controller, thereby simulating the operation of application software on the computing domain controller. This enables the priority development of the automotive multi-domain controller system platform and simultaneous verification through DV testing.

[0051] The beneficial effects of this invention are:

[0052] This invention proposes a domain controller testing method, system, and central multi-domain testing platform. The method involves a distributed, modular approach to scanning supported hardware modules and reading local configurations and test item configurations. This modular approach enhances program portability, significantly reduces development work, and allows for customized configurations to enable DV testing under different conditions, providing a more comprehensive range of testing functions. The proposed domain controller testing system can replace application software in automotive domain controllers, enabling priority development and DV testing of the domain controller's hardware platform. This solves the problem of being unable to conduct DV testing when application software is unavailable or incomplete, ensuring testing and verification during the development phase. It covers a wide range of hardware tests, supports more test items, reduces development burden, and accelerates the application deployment of automotive domain controllers. The coordinated use of a first, second, and third testing module provides a more comprehensive selection of testing functions, enabling priority development and DV testing of the automotive domain controller platform. Even without application software or with incomplete application software, testing and verification of the automotive domain controller during the development phase are not affected, thus optimizing the DV testing process. Attached Figure Description

[0053] Figure 1 This is a flowchart illustrating the domain controller testing method proposed in this embodiment of the invention.

[0054] Figure 2 This diagram illustrates the deployment of the domain controller testing system proposed in this embodiment of the invention.

[0055] Figure 3 This is a schematic diagram illustrating one possible architecture of the first test module proposed in this embodiment of the invention.

[0056] Figure 4 This is a schematic diagram illustrating the framework of the central architecture that integrates the vehicle driving domain controller and the cockpit domain controller proposed in this embodiment of the invention.

[0057] Figure 5 This diagram illustrates the connection of the hardware module under test on the cockpit domain controller SoC module proposed in this embodiment of the invention.

[0058] Figure 6 A schematic diagram illustrating the application of the third testing module proposed in this embodiment of the invention;

[0059] Figure 7 This is a flowchart illustrating the operation of the first test module, the second test module, and the third test module on the central multi-domain test platform proposed in this embodiment of the invention.

[0060] Figure 8This is a flowchart illustrating the central multi-domain testing method proposed in this embodiment of the invention.

[0061] Among them, 1-first test module; 2-second test module; 3-third test module. Detailed Implementation

[0062] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0063] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0064] The following is a detailed explanation:

[0065] Figure 1 This is a flowchart illustrating a domain controller testing method proposed in an embodiment of the present invention. See [link / reference]. Figure 1 The testing method includes:

[0066] S101. The first test module sends the start test command, test items, and test configuration to the second test module;

[0067] S102. The second test module calls the domain controller under test to start the simulation test according to the start test command, test items and test configuration, and the second test module and the third test module conduct data communication test;

[0068] S103. The second test module transmits the simulation test results and data communication test results to the first test module, and the first test module analyzes and verifies the simulation test results and data communication test results.

[0069] Before the first test module sends the start test command, test items, and test configuration to the second test module, the test method further includes: the second test module scanning its supported hardware modules and reading local configurations. Domain controllers have both hardware and software modules; this embodiment primarily tests the hardware modules of the domain controller. After the first test module initiates a connection, the second test module sends a list of domain controller tests to the first test module. The first test module matches its locally stored hardware module test configurations with the list of domain controller tests sent by the second test module, displays the test items and test metrics to the user, and then allows the user to customize the test configuration. After the above process is completed, the "second test module receives the start test command, test items, and test configuration sent by the first test module" described in step S101 can be achieved. At this point, the first test module sends the test configuration and test items to the second test module, and then the second test module can start the test.

[0070] exist Figure 1 The described method involves the cooperation of a first test module, a second test module, and a third test module. The first test module is used to issue start test commands, test items, and test configurations. The second test module is a crucial part, which uses common testing standards to call the domain controller for simulation testing. This allows the application software to run on the domain controller even before its development is complete. It also conducts data communication tests with the third test module to improve the comprehensive testing functions without affecting the testing and verification of the automotive domain controller during the development phase.

[0071] Furthermore, in this embodiment, by leveraging the POSIX API universal testing standard, the goal of using the same set of code for testing different SoC hardware platforms, different hardware modules, and different system architectures is achieved. This reduces the investment in development work, solves the problem of needing to develop different DV test software platforms for different hardware platforms and hardware states, and makes the entire testing method more portable, covers a wider range of hardware testing, supports more test items, and reduces the development burden.

[0072] The domain controller test includes communication, audio playback, video display, and / or load testing. Using the above testing methods, for the communication section within the automotive domain controller, in this embodiment of the invention, data transmission and reception between different SoC hardware platforms are performed at a set range (e.g., 1% to 100%), and data transmission and reception verification is conducted to simulate the communication transmission conditions of the automotive domain controller. For the audio playback section of the automotive domain controller, audio data is played to simulate the sound playback conditions of the automotive domain controller in actual automotive applications. For the video display section within the automotive domain controller, patterns and rendered graphics are simulated, and the frame rate is set to output to the video output port. The automotive domain controller video acquisition board acquires the video output data of the domain controller and performs video output data verification to simulate the image processing and display calling conditions within the automotive domain controller. For the load testing section within the automotive domain controller, the operation of different hardware modules under different automotive loads is simulated to simulate the actual operation of the domain controller.

[0073] Overall, this method utilizes the cooperation of the first test module, the second test module, and the third test module to replace the application software running in the vehicle domain controller, thereby enabling the hardware platform of the vehicle domain controller to be developed first and DV test verification to be carried out. This solves the problem that DV testing cannot be carried out when there is no application software or the application software has not been developed, and does not affect the test verification of the domain controller during the development phase.

[0074] After receiving the start test command, test items, and test configuration from the first test module, the second test module, based on the POSIX API general testing standard, performs DV tests using the same code across different systems running on the domain controller under test. This reduces development effort, offers strong portability, covers a wider range of hardware testing, and supports more test items. Here, the different systems on the domain controller under test can be Linux, Android, or QNX systems.

[0075] In this embodiment of the invention, the test items for data communication experiments conducted by the second test module and the third test module include: network throughput, packet loss rate, latency, and jitter.

[0076] The second testing module, based on the start test command, test items, and test configuration, invokes the domain controller under test to initiate a simulation test. While conducting data communication experiments with the third testing module, it outputs the data streams to be analyzed during the simulation test and data communication experiment to the first testing module. In this embodiment, the first testing module initiates a connection to the second testing module. The second testing module receives the start test command, test items, and test configuration from the first testing module. During the test, the second testing module performs three main tasks: acquiring or outputting data streams to the first testing module, conducting data communication experiments with the third testing module, and testing its supported peripheral hardware modules. After completing the test, the test results are sent to the first testing module, which analyzes and statistically processes the results, displays the results, and outputs a test report.

[0077] This invention proposes a domain controller testing system, the deployment of which is as follows: Figure 2 As shown, the system includes: a first test module 1, a second test module 2, and a third test module 3; see [link / reference] Figure 2 The first test module 1 runs on the host platform and is connected to the second test module 2 via a LAN or WLAN network; the second test module 1 runs on the domain controller under test and communicates with the third test module 3 through a communication interface; the third test module 3 runs on the data communication test platform.

[0078] exist Figure 2 In the diagram, the dashed box represents the combination of the first test module 1, the second test module 2, and the third test module 3. It can be seen that the first test module 1, the second test module 2, and the third test module 3 are deployed in a distributed manner to achieve a simple and convenient testing mode. In this embodiment of the invention, as... Figure 2 As shown, A, B, and C represent the deployment locations of the first test module 1, the second test module 2, and the third test module 3, respectively. The first test module 1 is connected to the second test module 2 via a LAN or WLAN network. This network connection method can meet the testing and analysis needs of some high-bandwidth hardware modules, further ensuring the effective analysis of the output data stream from the second test module 2 by the first test module 1. (See also...) Figure 2 The second test module 2 communicates with the third test module 3 through a communication interface; furthermore, it can be seen that the third test module 3 runs on a different platform than the second test module 2, which is associated with the second test module 2 and is to be tested for data communication.

[0079] In this embodiment, the host platform on which the first test module 1 runs is a Windows platform, see [link to documentation]. Figure 2Location A houses the first test module 1 and a Windows platform. Location B houses the domain controller and its connected peripheral hardware, the vehicle operating system OS, and the second test module 2. Location C houses the third test module 3, as well as the MCU, SoC, or cloud server associated with location B, along with drivers and hardware. In addition to the aforementioned setups at locations A, B, and C, a communication interface connecting locations A, B, and C is also provided. The first test module 1 acts as a communication client in the domain controller testing. The second test module 2 uses a test service and the POSIX API standard called by the test service, acting as a communication server in the testing. It requires the communication client, i.e., the first test module 1, to initiate a connection and perform configuration before the test can proceed. The third test module 3 consists only of programs that cooperate with the second test module 2 for data communication testing, running on other platforms associated with the second test module 2 that require communication testing, such as SoC, MCU, or cloud server. In specific implementation, the first test module 1 sends the start test command, test items, and test configuration information to the second test module 2; the second test module 2 receives the information sent by the first test module 1, calls the domain controller under test to start the simulation test based on the general test standard, and conducts a data communication test with the third test module 3, transmitting the simulation test results and data communication test results to the first test module 1; in this embodiment, the general test standard is the POSIX API general test standard; the third test module 3 cooperates with the second test module 2 to conduct the data communication test; finally, the simulation test results and data communication test results are analyzed and verified in the first test module 1.

[0080] In this embodiment, the first test module 1 is equipped with an application front-end and a general test framework. The general test framework is used to analyze and verify the simulation test results and data communication test results. The application front-end is used to provide test module selection, custom test items, application state simulation, display analysis and verification result data, and output test reports. The second test module 2 runs on different systems of the SoC hardware platform of the domain controller under test, such as Linux, Android, or QNX. It communicates with the general test framework described in the first test module 1 through a LAN / WLAN network. The second test module 2 is equipped with a test service program and the POSIX API general test standard required for writing the test service program. The second test module 2 communicates with the general test framework of the first test module 1 through a LAN / WLAN network. The third test module 3 is equipped with a communication interface test program. The second test module 2 communicates with the test program described in the third test module 3 through various communication interfaces (such as SPI, CAN, etc.). The first test module 1 is also equipped with a database section for storing test items, test indicators, and user-defined test configurations corresponding to different SoC hardware platforms and different hardware modules on the domain controller under test.

[0081] In this embodiment of the invention, based on the overall description above, a specific structural architecture for the first test module 1 is proposed, which can be found in the following documents. Figure 3 The first test module 1 will now be described in more detail with reference to the accompanying drawings.

[0082] like Figure 3 As shown, Figure 3 At its lowest level, a database is used to store test configuration items, test indicators, user-defined configurations and indicators for different platforms and hardware modules. TCP / UDP is used to complete communication with the second test module 2. Ethernet, Wi-Fi or USB can be used to achieve network connection, which is convenient for debugging. It supports connection within a local area network, supports remote debugging, and can ensure that there is enough bandwidth to support the acquisition of data information such as video streams. Figure 3 The middle layer consists of modules such as communication protocol, hardware module test configuration, test data flow analysis, test metrics, hardware standard metrics, and test indicators. The hardware standard metrics module and test indicator module correspond to the test module configuration module, and the communication protocol module corresponds to the test data flow analysis. These modules together constitute the general test framework of the first test module 1. This general test framework can basically cover the hardware test configuration and testing of the SoC hardware platform. Figure 3The top layer consists of two parts: one is the test module selection and custom test metrics and application state simulation function area, which allows users to configure according to the actual situation of the SoC hardware platform and the corresponding OS. This part is also the part that the first test module 1 will send to the second test module 2 after connecting with the second test module 2. The other part is the test result recording and display, which provides a graphical display function to display the test data in the form of icons and documents.

[0083] In practice, the first test module 1 connects to the second test module 2 via a network. The first test module 1 obtains the supported hardware modules and test items scanned by the second test module 2, and displays the predefined hardware module test standards and rules from the database through the application front end for testers to select and configure. After the testers have selected and configured, the first test module 1 sends a start test command along with the test items and related test configurations. Upon receiving the start command and related test configurations, the second test module 2, based on the received test configurations, starts application simulation experiments for each hardware module, including the call and operation of the domain controller under test and data communication experiments with the third test module 3.

[0084] During the testing process, the second testing module 2 sends the collected data stream to be analyzed and the test results of each hardware module to the first testing module 1. The first testing module 1 analyzes the data stream, verifies the test results of each hardware module, and displays the test verification status and outputs the test verification report through the application front-end charts.

[0085] This invention provides a central multi-domain test platform, which has several domain controllers, each domain controller is equipped with at least one SoC hardware platform, and the SoC hardware platforms are connected to each other via Ethernet and communication interfaces.

[0086] Each SoC hardware platform runs a second test module. At the same time, multiple first test module processes are started on the host platform. In this embodiment, the host platform is a Windows platform. Each first test module is connected to the second test modules running on different SoC hardware platforms. A third test module runs on the data communication test platform. The data communication test platform is different from the SoC hardware platform on which the second test modules run. Each second test module communicates with the third test module through a communication interface to conduct data communication tests.

[0087] Each first test module initiates a connection, acting as a "client" and the second test module as a "server." The first test module initiates a connection to the second test module (server), which waits for the first test module (client) to connect. The first test module selects test items, sets test metrics, and begins issuing test commands, test configurations, and test items. The second test module receives the start test command, test items, and test configuration from the first test module. Based on general testing standards, and according to the start test command, test items, and test configuration, it calls the domain controller under test to start a simulation test and conducts a data communication test with the third test module. The second test module ends the test, receives the data communication test results, and transmits the simulation test results and data communication test results back to the first test module. The test results of the domain controller hardware module and the data communication transmission test results are analyzed and verified in the first test module, and the test results are displayed and a test report is output in the first test module.

[0088] In this embodiment of the invention, the central multi-domain test platform further includes a communication unit. Several domain controllers include a driving domain controller and a cockpit domain controller. The driving domain controller is connected to the cockpit domain controller, and both the driving domain controller and the cockpit domain controller are connected to the communication unit. This achieves the fusion of the cockpit domain controller and the driving domain controller, forming a [structure / system]. Figure 4 The central architecture shown addresses the issue of separate designs between the cockpit domain controller and the driver domain controller, which prevent external communication networks from handling the bandwidth and speed required for data interaction. Furthermore, this central architecture serves as the target platform architecture for multi-domain controller testing, forming a central multi-domain test platform together with the multi-domain controller testing. Within this central architecture, multiple SoC hardware platforms exist, differing in themselves and their peripheral hardware modules. These SoC hardware platforms are connected via Ethernet and other communication interfaces (such as SPI and CAN). See also... Figure 4The driving domain controller includes a driving domain SoC module, a first MCU module, a second MCU module, a first autonomous driving SoC module, a second autonomous driving SoC module, a panoramic camera, a first front-view camera, a rear-view camera, a surround-view camera, and a second front-view camera. The first autonomous driving SoC module is associated with the panoramic camera and the first front-view camera, and the second autonomous driving SoC module is associated with the rear-view camera, the surround-view camera, and the second front-view camera. The first autonomous driving SoC module is connected to both the first and second MCU modules. The cockpit domain controller includes a cockpit domain SoC module, an instrument panel, an AR-HUD augmented reality head-up display, a central control screen, a passenger-side screen, and an audio module. The cockpit domain SoC module is associated with the instrument panel, the AR-HUD augmented reality head-up display, and an audio module. The system includes a head-up display, a central control screen, a passenger-side screen, and an audio module; the cockpit domain SoC module is connected to the driving domain SoC module; the communication unit includes a first Ethernet switch module, a second Ethernet switch module, and a 4G module; the first autonomous driving SoC module is connected to the second autonomous driving SoC module, with the first autonomous driving SoC module connected to both the first and second Ethernet switch modules, and the second autonomous driving SoC module connected to both the first and second Ethernet switch modules; the cockpit domain SoC module is connected to both the first and second Ethernet switch modules, the driving domain SoC module is connected to both the first and second Ethernet switch modules, and the first Ethernet switch module is connected to the 4G module. Figure 4 In this system, different SoC modules correspond to different SoC hardware platforms. Each second test module runs on a different SoC hardware platform, and multiple first test module processes are started on Windows to connect the second test modules on different SoC hardware platforms. This ensures that the tests between SoC hardware platforms do not affect each other and that the tests can be performed simultaneously, thereby improving the accuracy of application simulation.

[0089] The SoC hardware platform has several hardware modules under test. Each hardware module under test consists of three parts. The first part of the hardware module under test is tested by the SoC hardware platform itself. The second part of the hardware module under test is connected to the third test module to complete the communication data transmission test. The third part of the hardware module under test is connected to the first test module, which receives the data stream output by the third part of the hardware module under test based on the SoC hardware platform and performs analysis and verification.

[0090] In this embodiment of the invention, taking the cockpit domain controller SoC module as an example, some hardware modules to be tested on the cockpit domain controller SoC module are described. The cockpit domain controller SoC module is taken as a single SoC hardware platform, and the hardware modules to be tested on the SoC hardware platform can be found in [reference needed]. Figure 5 ,like Figure 5 As shown, the hardware modules under test include eMMC, DDR, USB, power supply, thermal management, display, camera, system, sensors, as well as RTC, audio, PCIe, CAN, Bluetooth, Wi-Fi, 4G modules, Ethernet, and communication interfaces. Some of these hardware modules can be tested by the SoC hardware platform itself, such as eMMC, DDR, and power supply. Other modules connect to the communication interface of the third test module and require the communication test program of the third test module to complete the experiment, such as the communication interface and 4G module. Still other modules require the first test module to use acquisition devices to collect data output from the SoC hardware platform for analysis and verification, such as the video output display interface test. The SoC hardware platform is the primary object of testing and verification. The second test module supports scanning and checking its supported hardware modules and configuring the hardware modules to be tested. The test content and indicators of each hardware module under test are displayed on the application front end of the first test module.

[0091] In this embodiment of the invention, the centralized architecture connects to a 4G module or a TBOX controller via an Ethernet switch module to enable Internet access to the backend server. During data communication tests of Internet access capabilities, a third test module runs on the backend server, connected to the 4G module or TBOX controller, to conduct the data communication test for Internet access capabilities. See also... Figure 6 The example application of the third test module shown illustrates a centralized architecture where an Ethernet switch module connects the 4G module and the TBOX controller. Internet access capability is achieved through either the 4G module or the TBOX controller. During Internet network capability testing, communication with a public network server is required. Therefore, the third test module is deployed on the backend server to work with the 4G module or the TBOX controller to complete the Internet network communication experiment. The second test module communicates with the third test module on the backend server to send and receive data, completing tests such as network throughput, packet loss rate, latency, and jitter. In this way, the third test module runs on a backend server separate from the central computing platform, achieving a separation of the data communication experiment from other test platforms.

[0092] In the central multi-domain test platform proposed in this embodiment of the invention, which targets multiple SoC hardware platforms, each SoC hardware platform can be tested independently on the central multi-domain test platform. For a single SoC hardware platform, Figure 7 This diagram illustrates the operational flow of the first, second, and third test modules on a central multi-domain test platform, showing their interaction. The second test module runs on a single SoC hardware platform. It first scans its supported hardware modules, reads its local configuration, and then waits for the first test module (client) to connect. The first test module (client) then initiates a connection, selecting the corresponding single SoC hardware platform to be tested. After establishing the connection, the second test module (server) sends its list of test hardware to the first test module. The first test module matches its locally stored hardware module test configuration with the hardware list, displaying testable options and indicators to the user on the application frontend. The user then customizes the configuration and indicators. After completion, the first test module sends the configuration and indicators back to the second test module, which then begins simulated application tests, including three types: collecting or outputting data streams to the first test module, conducting data communication tests with the third test module, and testing its own peripheral hardware. Finally, after completing the tests, the test results are sent back to the first test module. The first test module analyzes and statistically processes the results, displays them on the application frontend, and outputs a test report.

[0093] This invention proposes a central multi-domain testing method for testing multiple domain controllers of a central multi-domain testing platform. A flowchart is provided below. Figure 8 ,include:

[0094] S01. Configure several SoC hardware platforms in the same local area network;

[0095] S02. Deploy the second test module to each SoC hardware platform and run it. Deploy the third test module to the communication interface to be tested on each SoC hardware platform and run the third test module on the data communication test platform associated with the second test module.

[0096] S03. Start multiple first test module processes matching the number of SoC hardware platforms under test, and establish connections between each individual process of the first test module and different second test modules;

[0097] S04. The first test module displays the hardware devices, test items and test configurations supported by the corresponding SoC hardware platform under test. Select the hardware module to be tested and select different levels of simulation states.

[0098] S05. Start the synchronous test command. Each first test module process sends the test items and test configurations to its respective connected second test module.

[0099] S06. The second test module calls the domain controller under test to start a simulation test, and outputs the data stream to be analyzed and the test results to the first test module for analysis and verification.

[0100] When testing and verifying multiple domain controllers, a second test module is deployed and run on different SoC hardware platforms. A third test module is deployed for the communication interface under test on each SoC hardware platform. Multiple first test module processes are started on Windows to connect to the second test modules on different SoC hardware platforms. This ensures that the tests between SoC hardware platforms do not interfere with each other and that tests can be performed simultaneously, improving the accuracy of application simulation. By employing the cooperation of the first, second, and third test modules, different levels of application software simulation are selected to invoke the hardware operation of the domain controllers. This simulates the operation of application software on the computing domain controllers, enabling the priority development of the automotive multi-domain controller system platform and simultaneous verification through DV testing.

[0101] Based on the above description, the central multi-domain testing method proposed in this embodiment of the invention, when used for testing multiple domain controllers in a central multi-domain testing platform, generally includes the following process:

[0102] (1) Basic environment setup. Cross-compile the second test module to run on each SoC hardware platform in the central computing platform; write the third test module for the communication interface to be tested to other suitable platforms; configure each SoC hardware platform to be on the same local area network, and ensure that other hardware has normal operating conditions.

[0103] (2) Based on the number of SoC hardware platforms to be tested, multiple first test module processes are started. UDP broadcast scanning is enabled in the first test module to query the second test module services in the local area network. Each process of the first test module connects to different second test module services via TCP. After connection, the first test module will display the hardware devices supported by the corresponding SoC hardware platform, as well as the corresponding test configurations and indicators. Users can configure target indicators and select the hardware to be tested according to the actual situation, and select different levels of application simulation states, such as the state of the car being powered on, the state of the car after starting, the state of the car during driving, the state of the car during OTA, or directly test the upper limit indicators to test all hardware. The controller can perform periodic loops under different hardware conditions on the hardware modules of the SoC hardware platform to be tested, thereby simulating the application software running on the computing domain controller.

[0104] (3) After each first test module is configured, synchronous testing can be started using synchronization technology. Each first test module process sends its configuration to its respective connected second test module. After receiving the start test command, test items, and test configuration, the second test module performs its own application simulation test according to the start test command, test items, and test configuration. During the test, the data stream to be analyzed is output to its respective connected first test module. After the test ends, the test results are sent to the first test module process.

[0105] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A domain controller testing method, characterized in that, The testing method includes: The first test module sends the start test command, test items, and test configuration to the second test module; The second test module, based on the start test command, test items, and test configuration, and using general test standards, calls the domain controller under test to initiate a simulated test. The second test module also conducts a data communication test with the third test module, which runs on a different platform than the second test module, associated with and subject to the data communication test. The test items for the data communication test between the second and third test modules include: network throughput, packet loss rate, latency, and jitter. The second test module transmits the simulation test results and data communication test results to the first test module, which then analyzes and verifies the simulation test results and data communication test results. Before the first test module sends the start test command, test items, and test configuration to the second test module, the test method further includes: the second test module scanning the hardware modules it supports and reading the local configuration; after the first test module initiates a connection, the second test module sends the test list of the domain controllers to be tested to the first test module; the first test module matches the hardware module test configuration stored locally with the test list of the domain controllers to be tested sent by the second test module, displays the test items and test indicators to the user, and then the user customizes the test configuration.

2. The domain controller testing method according to claim 1, characterized in that, The domain controller test includes the communication section, audio playback section, video display section and / or load section; for the communication section of the domain controller, data transmission and reception between different SoC hardware platforms are performed at a communication transmission rate within a set range, and data transmission and reception verification is performed to simulate the communication transmission conditions of the domain controller; for the audio playback section of the automotive domain controller, audio data is played to simulate the sound playback conditions of the automotive domain controller in a real application scenario. For the video display portion of the domain controller, patterns and rendered graphics are simulated and output to the video output port at a set frame rate. The domain controller video acquisition board collects the video output data of the domain controller and performs video output data verification to simulate the image processing and display call conditions in the domain controller. For the load portion of the domain controller, the operation of different hardware modules is simulated under different loads to simulate the actual operation of the domain controller.

3. The domain controller testing method according to claim 1 or 2, characterized in that, The second test module runs on different systems on the domain controller under test.

4. The domain controller testing method according to claim 3, characterized in that, The different systems on the domain controller under test include: Linux system, Android system or QNX system.

5. A domain controller testing system, characterized in that, The system includes: The first test module, the second test module, and the third test module; The first test module runs on the host platform and connects to the second test module via a network. The second test module runs on the domain controller under test, and communicates with the third test module through a communication interface; The second test module, based on general testing standards, receives information sent by the first test module, calls the domain controller under test to start a simulation test, and conducts a data communication test with the third test module. It then transmits the simulation test results and the data communication test results back to the first test module. The test items for the data communication test between the second and third test modules include: network throughput, packet loss rate, latency, or jitter. The second test module scans the hardware modules it supports and reads the local configuration. After the first test module initiates a connection, the second test module sends the test list of the domain controllers to be tested to the first test module. The first test module matches the hardware module test configuration stored locally with the test list of the domain controllers to be tested sent by the second test module, displays the test items and test indicators to the user, and then the user customizes the test configuration. The third test module runs on a platform that is associated with the second test module, is to be tested for data communication, and is different from the platform on which the second test module runs.

6. The domain controller testing system according to claim 5, characterized in that, The network is a LAN or WLAN network.

7. The domain controller testing system according to claim 5, characterized in that, The information sent by the first test module includes the command to start the test, test items, and test configuration.

8. The domain controller testing system according to any one of claims 5 to 7, characterized in that, The first test module is equipped with an application front-end and a general test framework. The general test framework is used to analyze and verify the results of simulation tests and data communication experiments. The application front-end is used to provide test module selection, custom test items, application state simulation, display analysis and verification result data, and output test reports. The second test module is equipped with a test service program and the POSIX API general test standard that needs to be called when writing the test service program. The second test module communicates with the general test framework of the first test module through a LAN / WLAN network. The third test module is equipped with a communication interface test program.

9. The domain controller testing system according to claim 8, characterized in that, The first test module also includes a database section for storing test items, test metrics, and user-defined test configurations for different SoC hardware platforms and different hardware modules on the domain controller under test.

10. A central multi-domain testing platform, characterized in that, It includes several domain controllers, each of which has at least one SoC hardware platform, and the SoC hardware platforms are connected to each other via Ethernet and communication interfaces; Each SoC hardware platform runs a second test module. At the same time, multiple first test module processes are started on the host platform. Each first test module connects to the second test module running on a different SoC hardware platform. The third test module runs on a platform that is associated with the second test module, is to be tested for data communication, and is different from the platform where the second test module runs. Each second test module communicates with the third test module through a communication interface to conduct data communication tests. The test items for data communication experiments conducted by the second and third test modules include: network throughput, packet loss rate, latency or jitter; The second test module scans the hardware modules it supports and reads the local configuration. After the first test module initiates a connection, the second test module sends the test list of the domain controllers to be tested to the first test module. The first test module matches the hardware module test configuration stored locally with the test list of the domain controllers to be tested sent by the second test module, displays the test items and test indicators to the user, and then the user customizes the test configuration. The first test module sends the start test command, test items, and test configuration to the second test module. Based on the general test standard, the second test module calls the domain controller under test to start the simulation test according to the start test command, test items, and test configuration. The second test module also conducts a data communication test with the third test module. The second test module transmits the simulation test results and data communication test results to the first test module. The first test module analyzes and verifies the simulation test results and data communication test results.

11. The central multi-domain testing platform according to claim 10, characterized in that, The central multi-domain test platform also includes a communication unit. The plurality of domain controllers include a driving domain controller and a cockpit domain controller. The driving domain controller is connected to the cockpit domain controller, and the driving domain controller and the cockpit domain controller are also connected to the communication unit respectively.

12. The central multi-domain testing platform according to claim 11, characterized in that, The driving domain controller includes a driving domain SoC module, a first MCU module, a second MCU module, a first autonomous driving SoC module, a second autonomous driving SoC module, a panoramic camera, a first front-view camera, a rear-view camera, a surround-view camera, and a second front-view camera. The first autonomous driving SoC module is associated with the panoramic camera and the first front-view camera, and the second autonomous driving SoC module is associated with the rear-view camera, the surround-view camera, and the second front-view camera. The first autonomous driving SoC module is connected to both the first MCU module and the second MCU module. The cockpit domain controller includes a cockpit domain SoC module, an instrument panel, an AR-HUD augmented reality head-up display, a central control screen, a passenger screen, and an audio module. The cockpit domain SoC module is associated with the instrument panel, the AR-HUD augmented reality head-up display, the central control screen, the passenger screen, and the audio module. The cockpit domain SoC module is connected to the driver domain SoC module; The communication unit includes a first Ethernet Switch module, a second Ethernet Switch module, and a 4G module; the first autonomous driving SoC module is connected to the second autonomous driving SoC module, the first autonomous driving SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively, and the second autonomous driving SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively; the cockpit domain SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively, the driving domain SoC module is connected to the first Ethernet Switch module and the second Ethernet Switch module respectively, and the first Ethernet Switch module is connected to the 4G module.

13. The central multi-domain testing platform according to claim 10, characterized in that, The SoC hardware platform has several hardware modules under test, which are divided into three parts. The first part of the hardware module under test is tested by the SoC hardware platform itself. The second part of the hardware module under test is connected to the third test module to complete the data communication test. The third part of the hardware module under test is connected to the first test module. The first test module receives the data stream output by the third part of the hardware module under test based on the SoC hardware platform and performs analysis and verification.

14. The central multi-domain testing platform according to claim 10, characterized in that, Several domain controllers are merged to form a central architecture. The central architecture is connected to the 4G module or TBOX controller via an Ethernet switch module to enable Internet access to the backend server. When conducting data communication tests on Internet access capabilities, the third test module is run on the backend server. The third test module is connected to the 4G module or TBOX controller to conduct data communication tests on Internet access capabilities.

15. A central multi-domain testing method, characterized in that, The central multi-domain testing method is used for testing multiple domain controllers in a central multi-domain testing platform, including: Configure several SoC hardware platforms on the same local area network; The second test module is deployed to each SoC hardware platform for operation, and the third test module is deployed to the communication interface to be tested on each SoC hardware platform, and the third test module is run on a platform that is associated with the second test module, is to be tested for data communication, and is different from the platform on which the second test module runs. Multiple first test module processes matching the number of SoC hardware platforms under test are launched, and each process of the first test module establishes a connection with a different second test module. The second test module scans the hardware modules it supports and reads the local configuration. After the first test module initiates a connection, the second test module sends the test list of the domain controllers under test to the first test module. The first test module matches the hardware module test configuration stored locally with the test list of the domain controllers under test sent by the second test module, displays the test items and test indicators to the user, and then the user customizes the test configuration. The first test module displays the hardware devices, test items, and test configurations supported by the corresponding SoC hardware platform under test. Select the hardware module to be tested and choose different levels of simulation. Start the synchronous test command, and each first test module process will send the test items and test configurations to its respective connected second test module; The second test module calls the domain controller under test to start a simulation test, and outputs the data stream to be analyzed and the test results to the first test module for analysis and verification.

Images