Vehicle testing method and system and electronic equipment

Abstract

The invention discloses a vehicle testing method and system and electronic equipment, the testing system comprises a testing end and a tested end, and the testing end comprises a testing framework layer, a testing case layer, a service simulation layer and a bus driving layer. The test framework layer determines target test configuration information according to configuration operation of a user on the test configuration information based on test environment requirements, the test environment comprises a hardware-in-the-loop test environment and a software-in-the-loop test environment, and the test case layer is called to execute a first test case included in the target test configuration information; the test case layer generates a first test function according to the first test case and sends the first test function to the service simulation layer; the service simulation layer determines a first test signal corresponding to the first test function and sends the first test signal to the bus driving layer; and the bus driving layer carries out corresponding processing on the tested end according to the first test signal. Therefore, test processing in different test environments can be realized only by building one test system, the test workload is reduced, the labor cost is reduced, and the test efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle testing, and in particular to a vehicle testing method, system and electronic equipment. Background Art

[0002] With the widespread application of in-vehicle Ethernet and SOA (Service-Oriented Architecture) software platform design in vehicle electronic and electrical architecture, vehicle testing in various application scenarios has become increasingly important. Vehicle testing includes vehicle hardware in the loop testing (HIL) and software in the loop testing (SIL) to achieve different scenario testing for vehicle hardware devices and different scenario testing for vehicle software applications.

[0003] In the prior art, when performing vehicle testing, most of the time, vehicle testing is performed in a HIL environment. For example, a test end is built for the HIL environment. The test end generates a test signal by running various test cases corresponding to the artificially generated HIL environment test, and sends the test signal to the tested end to perform vehicle testing in the HIL environment.

[0004] Furthermore, in order to reduce the testing in the HIL environment, the software testing team will migrate relatively complex test projects to software applications to perform vehicle testing in the SIL environment. For example, a test terminal will be built for the SIL environment, and the test terminal will generate various test cases corresponding to the SIL environment test, run the test cases to generate a test service, and send the test service to the tested terminal to perform vehicle testing in the SIL environment.

[0005] However, this testing method requires building different test terminals for different test environments and creating corresponding test cases respectively, which increases the testing workload exponentially, increases the labor cost of test engineers, and increases the testing time and low testing efficiency. Summary of the invention

[0006] The present invention provides a vehicle testing method, system and electronic device, which are used to solve the problems in the prior art of needing to build different test terminals for different test environments and create corresponding test cases respectively, which increases the testing workload exponentially, increases the labor cost of test engineers, and takes a long time to test, and has low testing efficiency.

[0007] To solve the above technical problems, in the first aspect, an embodiment of the present invention discloses a vehicle testing method, which is applied to a vehicle testing system. The vehicle testing system includes a test end and a tested end. The test end includes a test framework layer, a test case layer, a service simulation layer, and a bus driver layer. The method includes: the test framework layer determines the target test configuration information according to the user's configuration operation on the test configuration information based on the test environment requirements, the target test configuration information includes a first test case, and calls the test case layer to execute the first test case, the test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment; the test case layer generates a first test function according to the first test case, and sends it to the service simulation layer; the service simulation layer determines a first test signal corresponding to the first test function, and sends the first test signal to the bus driver layer; the bus driver layer performs corresponding processing on the tested end according to the first test signal.

[0008] The vehicle testing method provided by the implementation method of the present application, the test framework layer included in the test end can configure the test configuration information based on the user's test environment requirements for the vehicle to determine the target test configuration information, such as the first test case. In this way, it is possible to determine whether to perform vehicle function testing in a hardware-in-the-loop test environment or in a software-in-the-loop test environment based on the user's test requirements. In this way, testing under different test environments can be achieved by only building a set of test systems. In addition, the test framework layer automatically determines the corresponding first test case from the unified test case pre-created in the test case layer based on the user's test environment requirements, so that the test case layer generates a test function according to the first test case, and then the service simulation layer determines the first test signal corresponding to the test function, and the bus driver layer performs corresponding processing according to the first test signal. In this way, vehicle testing under different test environments can be achieved based on the user's test requirements, without the need to create test cases under different test environments separately, reducing the test workload, reducing labor costs, and improving test efficiency.

[0009] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method, in which a bus driving layer performs corresponding processing on a tested end according to a first test signal, including: the bus driving layer sends the first test signal to the tested end; the tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driving layer.

[0010] By adopting the above technical solution, the tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer. In this way, the tested end can feedback test information, so that the testing end can determine the test result or perform other processing based on the test information, making the entire test process automated.

[0011] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method. When the test environment is a hardware-in-the-loop test environment, the method also includes: the bus driver layer sends the second test signal to the service simulation layer; the service simulation layer determines the corresponding first test callback function according to the preset function callback logic and the second test signal, and obtains the third test signal according to the second test signal, and sends the third test signal to the test case layer based on the first test callback function; the test case layer determines the test result according to the third test signal and / or determines the second test case according to the third test signal.

[0012] By adopting the above technical solution, in a hardware-in-the-loop test environment, the service simulation layer can obtain a third test signal based on the second test signal fed back by the tested end, and send the third test signal to the test case layer, and the test case layer determines the test result according to the third test signal and / or determines the second test case according to the third test signal. In this way, the test end can automatically determine the test result, or can continue to perform other tests based on the feedback signal of the tested end, so that the test can be automated, saving manpower and improving the test efficiency.

[0013] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method. When the test environment is a software-in-the-loop test environment, the method also includes: the bus driver layer sends the second test signal to the service simulation layer; the service simulation layer determines the corresponding second test callback function according to the preset function callback logic and the second test signal, and sends the second test signal to the test case layer based on the second test callback function; the test case layer determines the test result according to the second test signal and / or determines the second test case according to the second test signal.

[0014] By adopting the above technical solution, in a software-in-the-loop test environment, the service simulation layer can send the second test signal fed back by the tested end to the test case layer, and the test case layer determines the test result according to the second test signal and / or determines the second test case according to the second test signal. In this way, the test end can automatically determine the test result, or can continue to perform other tests based on the feedback signal of the tested end, so that the test can be automated, saving manpower and improving the test efficiency.

[0015] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method, in which, when the test environment is a hardware-in-the-loop test environment, a service simulation layer determines a first test signal corresponding to a first test function, including: the service simulation layer determines a service-oriented test signal corresponding to the first test function, and determines a first mapping relationship between a logical conversion function, a service-oriented test signal, and a signal-oriented test signal; the service simulation layer determines a logical conversion function corresponding to the service-oriented test signal according to the first mapping relationship, and converts the service-oriented test signal into a signal-oriented test signal based on the logical conversion function corresponding to the service-oriented test signal to obtain a first test signal.

[0016] By adopting the above technical solution, the test function of the test case is run based on the test case layer, and the service simulation layer can generate a signal-oriented test signal in the hardware-in-the-loop test environment based on the first mapping relationship to perform vehicle testing in the hardware-in-the-loop test environment. In this way, there is no need to write test cases separately for the hardware-in-the-loop test environment, but to generate test signals for the hardware-in-the-loop test environment based on the test cases, so as to realize testing in different test environments, reduce the workload of generating test cases, reduce labor costs, and improve test efficiency.

[0017] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method, in which a first mapping relationship is determined by a service simulation layer in the following manner: determining a signal-to-service logic table and a signal-oriented signal definition document, and generating a service-to-signal logic relationship table based on the signal-to-service logic table and the signal-oriented signal definition document; determining a first mapping relationship between a logic conversion function, a service-oriented test signal, and a signal-oriented test signal based on the service-to-signal logic relationship table.

[0018] By adopting the above technical solution, the vehicle test in the hardware-in-the-loop test environment can be realized by encapsulating the test signal, logic conversion function and other information in the service simulation layer. It makes it possible to complete the test in different test environments based on a set of test systems, which facilitates the test engineers to test the vehicle in different test environments and reduces the prerequisite development work of the test engineers.

[0019] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method, in which, when the test environment is a software-in-the-loop test environment, a service simulation layer determines a first test signal corresponding to a first test function, including: the service simulation layer determines a service-oriented signal definition document, and determines a service-oriented test signal according to the service-oriented signal definition document; the service simulation layer determines the service-oriented test signal corresponding to the first test function as the first test signal.

[0020] By adopting the above technical solution, in a software-in-the-loop test environment, the service simulation layer can directly generate service-oriented test signals based on the service-oriented signal definition document, and then determine the service-oriented test signals corresponding to the test functions, thereby realizing vehicle testing in a software-in-the-loop test environment without manually generating test cases, thereby reducing the workload of test engineers.

[0021] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method, in which the test cases included in the test case layer are generated by the test case layer in the following manner: determining scenario service definition information, and generating node network information according to the scenario service definition information; determining a service-oriented signal definition document, and verifying the node network information according to the service-oriented signal definition document to obtain a verification result; when the verification result is that the verification is passed, generating at least one call sequence according to the node network information; and generating a test case according to the call sequence.

[0022] By adopting the above technical solution, the scenario service definition information is converted into node network information, and then a call sequence is generated based on the node network information, and various test cases are generated according to the call series. In this way, different test cases can be automatically generated based on the test scenario without manual writing of test cases. In addition, by generating test cases based on node network information, different test cases can be generated based on different call sequences, making the test more comprehensive.

[0023] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method, in which a test case layer verifies and processes the node network information according to a service-oriented signal definition document to obtain a verification result, including: the test case layer determines the node information of each node included in the node network information according to the service-oriented signal definition document, performs a first verification process on the node information, obtains a first verification result, and determines the node type of each node when the first verification result is that the verification passes; for nodes whose node type is a self-loop node, the test case layer prunes the self-loop node and determines the self-loop node as a waiting node; for nodes whose node type is other types other than self-loop nodes, the test case layer Determine the starting node, establish a service status table, store the node information of each node in the service status table, and perform a depth-first traversal based on the starting node to perform a second verification process on each node to obtain a second verification result, wherein, if the last associated node of the node is determined to be the end node based on the depth-first traversal, then the second verification result is determined to be a passed verification; if the last associated node of the node is determined to be a conditional node based on the depth-first traversal, and it is determined according to the service status table that the node cannot jump to the conditional node, and there is no other node to jump to, then the second verification result is determined to be a failed verification, and the conditional node is a self-loop node or a conditional judgment node; the verification result for the node network information is obtained based on the first verification result and the second verification result.

[0024] By adopting the above technical solution, by verifying the node network information, it is possible to ensure that the generated test cases are executable. This can avoid the problem of test failure due to the inability to execute the test cases and the inability to eliminate the cause of the failure, thereby improving the test accuracy.

[0025] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method, in which, when the test environment is a hardware-in-the-loop test environment, the tested end is an electronic control unit under test, and the electronic control unit under test includes an underlying driver, middleware and an in-vehicle scenario application. The tested end performs corresponding processing according to a first test signal, generates a second test signal, and sends the second test signal to a bus driver layer, including: the underlying driver converts the first test signal and sends it to the middleware; the middleware generates a service notification message according to the converted first test signal, and sends it to the in-vehicle scenario application; the in-vehicle scenario application generates a corresponding second test signal according to the service notification message, and sends the second test signal to the middleware; the middleware converts the second test signal and sends it to the underlying driver; the underlying driver sends the converted second test signal to the bus driver layer.

[0026] By adopting the above technical solution, in a hardware-in-the-loop test environment, the first test signal is sent to the electronic control unit under test, and the electronic control unit under test can generate a second test signal based on the first test signal. In this way, functional testing of the vehicle electronic control unit can be achieved and the vehicle hardware test can be completed.

[0027] According to another specific embodiment of the present invention, an embodiment of the present invention discloses a vehicle testing method. When the test environment is a software-in-the-loop test environment, the tested end is a virtual machine, and the virtual machine includes a virtual image and a vehicle-mounted scenario application. The tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer, including: the virtual image generates a service notification message according to the first test signal, and sends it to the vehicle-mounted scenario application; the vehicle-mounted scenario application generates a corresponding second test signal according to the service notification message, and sends the second test signal to the virtual image; the virtual image sends the second test signal to the bus driver layer.

[0028] By adopting the above technical solution, in a software-in-the-loop test environment, the first test signal is sent to the virtual image, and the virtual image can generate a second test signal based on the first test signal. In this way, there is no need to test the software application of the real vehicle, but the vehicle scenario application can be deployed in the virtual machine to implement functional testing of the vehicle software function, saving testing costs and simplifying testing operations.

[0029] In the second aspect, an embodiment of the present invention also discloses a vehicle testing method, which is applied to a test end, and the test end includes a test framework layer, a test case layer, a service simulation layer and a bus driver layer. The method includes: the test framework layer determines the target test configuration information according to the user's configuration operation on the test configuration information based on the test environment requirements, the target test configuration information includes a first test case, and calls the test case layer to execute the first test case, and the test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment; the test case layer generates a first test function according to the first test case, and sends it to the service simulation layer; the service simulation layer determines a first test signal corresponding to the first test function, and sends the first test signal to the bus driver layer; the bus driver layer performs corresponding processing on the tested end according to the first test signal.

[0030] In the third aspect, an embodiment of the present invention also discloses a vehicle testing method, which is applied to a tested end, and the tested end receives a first test signal sent by a bus driver layer included in the test end, so as to perform corresponding processing according to the first test signal, wherein the first test signal is determined by a service simulation layer included in the test end as a first test signal corresponding to a first test function, and the first test signal is sent to the bus driver layer, and the first test function is generated by a test case layer included in the test end according to the first test case and sent to the service simulation layer, and the first test case is determined by a test framework layer included in the test end according to the user's configuration operation on the test configuration information based on the test environment requirements. The target test configuration information includes a first test case, and the test case layer is called to execute the first test case, and the test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment.

[0031] In the fourth aspect, an embodiment of the present invention also discloses a vehicle testing system, comprising: a test end and a tested end, the test end comprising a test framework layer, a test case layer, a service simulation layer and a bus driver layer, wherein the test framework layer is used to determine the target test configuration information according to the user's configuration operation on the test configuration information based on the test environment requirements, the target test configuration information includes a first test case, and calls the test case layer to execute the first test case, the test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment; the test case layer is used to generate a first test function according to the first test case, and send it to the service simulation layer; the service simulation layer is used to determine a first test signal corresponding to the first test function, and send the first test signal to the bus driver layer; the bus driver layer is used to perform corresponding processing on the tested end according to the first test signal.

[0032] In a fifth aspect, an embodiment of the present application provides an electronic device, including a test terminal included in a vehicle test system.

[0033] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, it is used to implement a vehicle testing method provided in any one of the implementations of the first aspect above.

[0034] In a seventh aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements a vehicle testing method as provided in any one of the implementations of the first aspect above.

[0035] It can be understood that the beneficial effects of the second to seventh aspects mentioned above can also be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1is a structural schematic diagram of a vehicle testing system provided by an embodiment of the present invention;

[0037] Figure 2 is a structural schematic diagram of another vehicle testing system provided by an embodiment of the present invention;

[0038] Figure 3 is a schematic diagram of an application scenario for vehicle testing provided by an embodiment of the present invention;

[0039] Figure 4 is a flow chart of a vehicle testing method provided by an embodiment of the present invention;

[0040] Figure 5 is a schematic diagram of the structure of the test case layer provided by an embodiment of the present invention;

[0041] Figure 6 is a schematic diagram of a calling sequence provided by an embodiment of the present invention;

[0042] Figure 7 It is a schematic diagram of a flow chart of generating a test case provided by an embodiment of the present invention;

[0043] Figure 8 It is a structural diagram of a service simulation layer in a hardware-in-the-loop test environment provided by an embodiment of the present invention;

[0044] Fig. 9 is a schematic diagram of generating a test signal provided by an embodiment of the present invention;

[0045] Fig.10 is a schematic diagram of the structure of a bus driver layer provided by an embodiment of the present invention;

[0046] Fig.11 is a flow chart of another vehicle testing method provided by an embodiment of the present invention;

[0047] Fig.12 It is a schematic diagram of the structure of the service simulation layer in a software-in-the-loop test environment provided by an embodiment of the present invention;

[0048] Fig.13 is a flow chart of another vehicle testing method provided by an embodiment of the present invention;

[0049] Fig.14 It is a flow chart of a vehicle testing method executed by a vehicle testing system in a hardware-in-the-loop testing environment provided by an embodiment of the present invention;

[0050] Fig.15 It is a flow chart of a vehicle testing method executed by a vehicle testing system in a software-in-the-loop testing environment provided by an embodiment of the present invention;

[0051] Fig.16It is a structural schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0052] With the widespread application of in-vehicle Ethernet and SOA software platform design in vehicle electronic and electrical architecture, more and more in-vehicle scenario applications have begun to carry out logic design and development for the service interface of the middleware. This design greatly reduces the adaptation and development costs of the upper-layer application software of the vehicle. In addition, in this case, the description of the software requirements of the in-vehicle scenario application will be interface-based and service-based, and the development engineers of the in-vehicle scenario application will only focus on the logic of the middleware service interface, so that when conducting vehicle testing, by configuring the call function of the middleware service interface and the signal transmission test case for the middleware service interface, the functional test for different vehicle scenarios can be realized.

[0053] In the prior art, vehicle testing is usually carried out in a HIL test environment, by running pre-configured test cases, and sending test signals based on middleware to test the electronic control unit (Electronic Control Unit, referred to as ECU) under test. For example, a test end is built for the HIL environment, and the test end generates test signals by running various test cases corresponding to the artificially generated HIL environment test, and sends test signals to the tested end to perform vehicle testing under the HIL environment. And when generating test cases under the HIL environment, the software testing team needs to analyze the software demand logic of the vehicle scene application, obtain the service call logic and service parameters of the vehicle under different test scenarios, and then determine the signal logic and parameters corresponding to the service by consulting the signal to service logic table, and finally convert the service signal into CAN / LIN and other signals, write the scenario test script with CAN / LIN and other signals as input and output parameters, and test the vehicle electronic control unit based on the scenario test script. However, when encountering relatively complex test scenarios, it is necessary to manually perform signal logic and parameter queries for services, and manually convert service signals into CAN / LIN signals and then generate test case scripts. The work cost will increase significantly, making the test workload doubled, and the labor cost of test engineers will also increase accordingly. And when there are many services, it is very easy for the conversion logic of services to signals to go wrong, which will cause the test case script to generate errors and fail to run or run incorrectly. If there is a problem with the test result, it is impossible to rule out whether it is a problem with the test case script or the device under test, which makes the test accuracy low and the problem difficult to locate. Moreover, in actual test scenarios, there are often problems with the vehicle middleware itself, which makes the test results of vehicle testing only in the HIL test environment inaccurate.

[0054] Therefore, the software testing team will migrate the relatively complex scenario logic to the application software for testing, that is, the vehicle test in the SIL environment is proposed. For example, a test end is built for the SIL environment, and the test end generates various test cases corresponding to the SIL environment test, so as to run the test cases to generate test services, and send the test services to the tested end for vehicle testing in the SIL environment. In the SIL environment, more service interface logic can be covered at the software module level as much as possible, and the services of the middleware can be replaced by inserting stub codes (that is, the middleware is replaced by the written code to realize the transmission of the test signal), so as to fully carry out testing work on the vehicle scene application. However, in the SIL environment, because the middleware is not involved, only the software test of the vehicle scene application can be covered, and it is difficult to cover the problem of the middleware, which greatly reduces the test scope of the vehicle scene. In addition, the SIL test generally uses a specially compiled virtual image, which is different from the actual ECU environment. The result is difficult to characterize the adequacy of the vehicle intelligent scene application test.

[0055] Therefore, the bus data and test methods concerned in these two test modes are completely different in different test environments. Vehicle testing in any environment has the problem of incomplete test coverage. Moreover, compared with the traditional testing work for vehicle-mounted ECUs, different test terminals are built for different test environments, and test cases are generated separately, which increases the test workload exponentially, and the labor cost of test engineers also increases accordingly. The test time is long, the test efficiency is low, and the test quality (that is, the test accuracy) cannot be effectively guaranteed.

[0056] Based on this, the implementation of the present application provides a vehicle testing method, which is applied to the vehicle testing system provided by the implementation of the present application. A platform-based testing system that can adapt to both HIL and SIL testing environments is designed for vehicle-mounted intelligent scene function testing based on the SOA software architecture. The testing system includes a test end and a tested end, wherein the test end includes a test framework layer, a test case layer, a service simulation layer, and a bus driver layer. The test framework layer can determine whether to perform vehicle function testing in a hardware-in-the-loop test environment or a software-in-the-loop test environment based on the user's test requirements. In this way, testing in different test environments can be achieved by only building a set of test systems. In addition, there is no need to generate test cases in different test environments separately, which reduces the testing workload, reduces labor costs, and improves testing efficiency.

[0057] Next, the vehicle testing method and vehicle testing system provided by the implementation of the present application are described in detail.

[0058] See also Figure 1The vehicle testing system disclosed in the implementation of the present application includes a testing end and a tested end, wherein the testing end includes a testing framework layer, a testing case layer, a service simulation layer and a bus driver layer.

[0059] The test framework layer is used to determine the target test configuration information according to the user's configuration operation on the test configuration information based on the test environment requirements. The target test configuration information includes a first test case, and calls the test case layer to execute the first test case. The test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment.

[0060] Exemplarily, the test end is an electronic device such as a computer (PC), which provides a test interface, and the user configures it with the test configuration information based on the test environment requirements, so that the test framework layer obtains the target test configuration information based on the configuration operation of the test configuration information. For example, the test engineer selects the test case and the relevant configuration information of the test according to the test requirements, so that the test end can perform the test in the HIL test environment or in the SIL test environment based on the test case selected by the user.

[0061] The test case layer is used to generate a first test function according to the first test case and send it to the service simulation layer.

[0062] Exemplarily, the test case layer generates multiple test cases based on the test logic related to the functional design, and when the test framework layer calls the test case layer to test the first test case, it generates related test functions that can implement service function calls.

[0063] Moreover, in this application, the test case layer also has the ability to analyze the in-vehicle scenario services under different combination tests.

[0064] The service simulation layer is used to determine a first test signal corresponding to the first test function, and send the first test signal to the bus driver layer.

[0065] Exemplarily, the service simulation layer is used to manage and load the conversion logic and simulation logic between the service interface and the external protocol, that is, based on the simulation logic, and based on the test function registered to the service simulation layer by the test case layer, the corresponding service simulation signal is determined, and the service simulation signal is converted into a signal type based on the conversion logic to obtain a test signal (that is, a first test signal), and the first test signal is sent to the bus driver layer.

[0066] The bus driving layer is used to perform corresponding processing on the tested end according to the first test signal.

[0067] Exemplarily, the bus driver layer uniformly encapsulates common external devices such as in-vehicle Ethernet (such as SOME / IP protocol), CAN bus, LIN bus, etc., to send SOME / IP type test signals or CAN / LIN type test signals to the tested end, so that the tested end performs corresponding processing according to the received test signals.

[0068] The vehicle testing system provided by the implementation method of the present application facilitates the rapid adaptation of test cases for different in-vehicle intelligent scenario functions in different test environments of the same test platform, and can cover the test environments at both the SIL and HIL levels at the same time, thereby reducing the manpower input in the testing work by several times, shortening the testing cycle of platform-based intelligent vehicles, and facilitating the testing of different functions under the condition of rapid iteration of in-vehicle application software, thereby ensuring high software quality.

[0069] Further, see Figure 2 (a), in one implementation of the present application, when the test environment is a hardware-in-the-loop test environment, the tested end is the electronic control unit under test, and the bus driver layer establishes a communication connection with the vehicle ECU through a bus interface device.

[0070] Among them, the vehicle ECU can be an ECU control chip on a real vehicle, or it can be a separate ECU control chip deployed with vehicle scenario applications and vehicle functions.

[0071] See also Figure 2 (b) When the test environment is a software-in-the-loop test environment, the tested end is a virtual machine, which includes a virtual network card (also known as a virtual bridge) and a virtual image. The bus driver layer establishes a communication connection based on the virtual network card and the virtual image.

[0072] The vehicle test system provided by the implementation method of this application adopts a layered architecture design, which includes three major parts from top to bottom: test case layer, service simulation layer, and bus driver layer. The test framework layer can manage and call the test case layer, service simulation layer, and bus driver layer, and can flexibly switch the test environment and combine test scenarios according to test requirements. In this way, combined with the general test framework, the hardware in the loop test environment is formed with the bus interface device, vehicle ECU and other hardware as a whole, and the software in the loop test environment is formed with the virtual bridge and the virtual image containing the software module as a whole.

[0073] Further, see Figure 3The vehicle testing method and system provided by the implementation of this application are mainly for testing in-vehicle intelligent scenarios. There are two main functional architectures for in-vehicle intelligent scenario testing. The first is a dynamic scenario call architecture based on the scenario service definition document, that is, the intelligent scenario call management module completes the display of the in-vehicle intelligent scenario by loading, parsing, and running scenario service definition documents 1 to n. The second is directly based on the in-vehicle intelligent scenario application, and directly calls the interface of the in-vehicle middleware in the executable binary file to complete the display of each in-vehicle intelligent scenario.

[0074] That is, in this application, for vehicle testing of in-vehicle intelligent scenarios, the in-vehicle intelligent scenarios can be different intelligent scenarios parsed based on the scenario service definition document, or different intelligent scenarios called based on in-vehicle intelligent scenario applications (such as various software applications). In this way, the testing of in-vehicle intelligent scenarios for vehicles can be more comprehensive.

[0075] Next, see Figure 4 In the implementation of the present application, the vehicle testing system executes the vehicle testing method including the following steps:

[0076] S110, the test framework layer determines the target test configuration information according to the user's configuration operation on the test configuration information based on the test environment requirements, the target test configuration information includes a first test case, and calls the test case layer to execute the first test case. The test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment.

[0077] S120: The test case layer generates a first test function according to the first test case, and sends it to the service simulation layer.

[0078] S130, the service simulation layer determines a first test signal corresponding to the first test function, and sends the first test signal to the bus driver layer.

[0079] S140: The bus driver layer performs corresponding processing on the tested end according to the first test signal.

[0080] The vehicle testing method provided by the implementation of the present application, the test framework layer included in the test end can configure the test configuration information based on the user's test environment requirements for the vehicle to determine the target test configuration information, such as the first test case, so that it can be determined based on the user's test requirements to perform vehicle function testing in a hardware-in-the-loop test environment, or to perform vehicle function testing in a software-in-the-loop test environment. In this way, testing in different test environments can be achieved by only building a set of test systems. In addition, the test framework layer determines the first test case based on the user's test environment requirements, so that the test case layer generates a first test function according to the first test case, and then the service simulation layer determines the first test signal corresponding to the first test function, and the bus driver layer performs corresponding processing according to the first test signal. In this way, vehicle testing in different test environments can be achieved based on the user's test requirements, without the need to generate test cases in different test environments separately, reducing the test workload, reducing labor costs, and improving test efficiency.

[0081] For step S110, if the test engineer chooses to test the in-vehicle intelligent scenario under the hardware-in-the-loop test environment (as a test item in the vehicle test), the electronic device is connected to the ECU under test, and the test system (such as test software) is opened. The test configuration under the hardware-in-the-loop test environment is performed based on the test interface provided by the test framework layer to obtain the target test configuration information. For example, if the user chooses to perform HIL testing on the interface, the test framework layer calls the pre-generated HIL test configuration file to configure the test case layer, service simulation layer, and bus driver layer under the HIL environment based on the HIL test configuration file, so that the test case layer, service simulation layer, and bus driver layer are in the HIL test environment, and the bus driver layer establishes a communication connection with the ECU under test through the bus interface device.

[0082] It should be noted that the bus driver layer may establish a communication connection with the ECU under test through the bus interface device, and may establish a communication connection with the physical test vehicle to establish a communication connection with each ECU under test on the test vehicle. It may also be that the electronic device directly establishes a communication connection with the bus interface device through a USB connection, and the bus interface device then establishes a communication connection with the test vehicle. It may also be that the electronic device directly establishes a communication connection with the bus interface device through a USB connection, and the bus interface device then establishes a communication connection with the circuit board chip of the ECU under test.

[0083] Furthermore, if the user chooses to perform a SIL test on the interface, the test framework layer calls the pre-generated SIL test configuration file to configure the test case layer, service simulation layer, and bus driver layer in the SIL environment based on the SIL test configuration file, so that the test case layer, service simulation layer, and bus driver layer are in the SIL test environment, and the bus driver layer establishes a communication connection with the virtual machine through the virtual network card.

[0084] It should be noted that the bus driver layer establishes a communication connection with the virtual machine through the virtual network card, and the bus driver layer calls the virtual machine on the electronic device based on the virtual network card. The virtual machine includes a virtual image and stores software applications that can realize various in-vehicle intelligent scenarios.

[0085] Furthermore, after the user selects the test environment, the test framework layer will display information such as the test case name of each test case on the test interface, so that the user can select the first test case from the test cases based on the test requirements. The test framework layer determines the first test case selected by the user and calls the test case layer so that the test case layer executes the first test case.

[0086] In one implementation of the present application, Figure 5 As shown, the test case layer includes a scenario service definition document parsing module, a scenario node network verification module, a scenario node network derivation module, and a test case script generation module. Among them, the test case of the test case layer (such as the first test case) is generated by the test case layer in the following way:

[0087] First, the scene service definition document parsing module determines the scene service definition information and generates node network information according to the scene service definition information.

[0088] Exemplarily, the scenario service definition document parsing module imports a formatted scenario service definition file (as an example of scenario service definition information), parses the calling interface of the SOME / IP service described in the scenario service definition document (i.e., the SOME / IP service interface), the relevant parameter values ​​of the interface, and the calling sequence and calling logic for calling the interface, so as to determine the test logic (i.e., the interface calling steps and the corresponding calling interfaces) in different vehicle-mounted intelligent scenarios, regards the calling steps of each service interface as a network node, and connects them in series into a node network table (e.g., Figure 5 The node network structure example shown in FIG. 10A ) is used as an example of node network information. The calling logic may involve obtaining and judging the service interface, etc.

[0089] That is, in this application, by parsing the scene service definition document, the calling order (that is, the calling sequence) and the calling method (that is, the calling logic) for the SOME / IP service interface are parsed, and the calling logic of each calling step of the calling sequence is converted into a network node according to the calling sequence, forming a node network structure view with a calling order and a calling relationship, and the parsed node network information is sent to the scene node network verification module.

[0090] Furthermore, the scene node network verification module determines a service-oriented signal definition document, performs verification processing on the node network information according to the service-oriented signal definition document, and obtains a verification result.

[0091] Exemplarily, the node network information is verified after being transmitted to the scene node network verification module.

[0092] In one implementation of the present application, the scenario node network verification module included in the test case layer verifies the node network information according to the service-oriented signal definition document to obtain the verification result in the following manner.

[0093] First, the scene node network verification module determines the node information of each node included in the node network information according to the service-oriented signal definition document, performs a first verification process, obtains a first verification result, and determines the node type of each node when the first verification result is verification passed.

[0094] Exemplarily, the scene node network verification module will verify the SOME / IP service interface and the parameter value of the interface corresponding to the node according to the imported SOME / IP definition document. That is, based on the SOME / IP definition document, it is determined whether the SOME / IP service interface is the required interface, and whether the format of the parameter value of the interface is the specified format, and whether the parameter value is the correct parameter value.

[0095] Furthermore, for a node whose node type is a self-loop node, the test case layer performs pruning processing on the self-loop node and determines the self-loop node as a waiting node.

[0096] Exemplarily, all nodes in the node network information are then traversed to determine the self-ring nodes (i.e., self-loop nodes) (e.g., rollback1 nodes, rollback2 nodes, and rollback3 nodes in the node network structure example), prune the self-ring nodes, and mark them as waiting nodes. Among them, the self-loop nodes are also FOR, WHILE, and other nodes.

[0097] Furthermore, for nodes whose node types are other than self-loop nodes, the test case layer determines the starting node and establishes a service status table, stores the node information of each node in the service status table, and performs a depth-first traversal based on the starting node to perform a second verification process on each node to obtain a second verification result, wherein, if the last associated node of the node is determined to be the end node based on the depth-first traversal, then the second verification result is determined to be a passed verification; if the last associated node of the node is determined to be a conditional node based on the depth-first traversal, and it is determined according to the service status table that the node cannot jump to the conditional node, and there are no other nodes to jump to, then the second verification result is determined to be a failed verification, and the conditional node is a self-loop node or a conditional judgment node.

[0098] Exemplarily, the nodes in the node network information are finally cyclically checked. First, a service status table is constructed, and the service status and parameter values ​​of each node are recorded in the service status table, wherein the service status is whether the node can be executed normally or whether it needs to be cyclically executed. Determine the verified node (for example, the START node in the node network structure example) (as an example of the starting node), start from the verified node, perform a depth-first traversal to the associated node, and record the status and parameters of the SOME / IP service node corresponding to the associated node to the service status table, wherein the service status of the node is whether the node is available, and the parameter value is the corresponding name that can call the service, etc. If the key node is determined to be a conditional judgment node (for example, check1 node, check2 node) or a conditional loop node (for example, rollback1 node, rollback2 node, rollback3 node), then pull the service status of the node from the service status table to determine whether it is possible to jump from the previous node to the associated node. If the key node is an end node (such as an END node), it is determined that the node to be checked can end to the last associated node (i.e., the end node). If there is no other node to jump to, and the last node is not an end node, it is determined that the node to be checked cannot end to the last associated node. It is determined that the check of the node to be checked has failed, an error is reported, and the error information is output and displayed to the test interface of the test framework layer, and the test engineer performs manual verification and processing.

[0099] In this way, the loop performs associated node verification on each verified node based on a depth-first traversal method until all nodes are verified and checked, and then outputs a second verification result.

[0100] A verification result for the node network information is obtained according to the first verification result and the second verification result.

[0101] Exemplarily, if the first verification result is a pass and the second verification result is also a pass, then the verification result for the node network information is determined to be a pass. If the first verification result is a fail and / or the second verification result is a fail, then the verification result for the node network information is determined to be a fail.

[0102] That is, in the present application, a verified node is determined as the starting node, and a depth-first traversal is performed to the associated nodes of the verified node, and the service status and parameter value service status table of each node are recorded. If the process from the verified node to the last associated node can be completed, then it is determined that the verified node has passed the verification; if the process from the verified node to the last associated node cannot be completed and there is no other node to jump to, then it is determined that the verified node has failed the verification.

[0103] Further, when it is determined that the verification result is passed, the scene node network derivation module generates at least one call sequence according to the node network information.

[0104] Exemplarily, when the node network is verified by the scene node network verification module and the verification is passed, the scene node network derivation module will be entered to perform logical derivation before the test case is generated. First, the starting node (such as the START node) will be found for recording, and then the derivation will continue from the child nodes of the starting node in sequence. If the child node is an action node (such as action1 node, action2 node, action3 node), the action node is, for example, a step that needs to call the service interface for numerical modification, etc., then a call sequence group is created, and the action node is recorded in the sequence group, and the child node is continued to traverse until the next node is not an action node. At this time, the call sequence group is frozen and stored reasonably. That is, from the overall point of view, the essence is to compress the continuous action nodes into a step in a test case to simulate the service. In this way, when the call sequence group is called to wait for the service request, it can be directly verified based on the assertion method whether the request call of the entire call sequence group is reasonable. Compared with the way of waiting for service requests one by one and making assertions, this design is not easy to cause the test case to fail due to data loss in the case of fast requests.

[0105] For example, based on the node network, a call sequence group of action 1 (action1), action 2 (action2), and action 3 (action3) is generated for asynchronous calls, a call sequence group of action 1 and action 3 is generated for asynchronous calls, and a call sequence group of action 2 (action2) is generated.

[0106] When the scene node network derivation module identifies a selection node, it will form multiple call sequences that match the branch according to different conditions and the call sequence groups that have been formed in the past. Figure 6 The node network shown, according to the generation logic of the branch structure, is two call sequences: [starting node, calling sequence group (including 3 action nodes), selection 1, calling sequence group (including 2 action nodes), ending node] and [starting node, calling sequence group (including 3 action nodes), selection 2, cyclic sequence group (including 1 action node) marked as cyclic sequence after pruning].

[0107] That is, in the implementation of the present application, the starting node is determined, a depth-first traversal is performed from the starting node, the action node is determined, a call sequence group is generated based on the action node, the selection node and the self-loop node are determined, and a call sequence is generated based on the selection node and the self-loop node.

[0108] Furthermore, the test case script generation module generates test cases according to the called sequence.

[0109] Exemplarily, after the scene node network deduction module generates the call sequence, it sends the call sequence to the test case script generation module. The test case script generation module receives the branch logic call sequence transmitted by the scene node network deduction module and generates the test case script.

[0110] For example, Figure 7 As shown, the call sequence includes relevant information of each node and the service corresponding to the node (such as service information, service parameters, and usage methods). If the service interface is determined to be of event type according to the service information and the scenario application of the interface is consumer (consumer subscription (i.e., active signal sending logic)), then the function in the test case script is determined to be a periodic sending function, which takes the SOME / IP data object as an input parameter and contains the logic of periodically sending the SOME / IP data object. The periodic sending function is to run the test case so that the simulation layer actively sends a test signal to the next period based on the periodic sending function for testing.

[0111] If the service interface is determined to be of event type and the scenario application of the interface is porvider (provider (i.e., server-side execution logic)) according to the service information, the function in the test case script is determined to be a test assertion function, which takes the SOME / IP data object as an input parameter, and contains logic for determining whether the SOME / IP data object conforms to the value defined in the call sequence. The test assertion function is to determine whether each test function conforms to the test sending logic and test logic when sending test signals such as SOME / IP data objects when executing various test functions, so as to ensure the normal execution of the test case, eliminate the problem of test case errors, and thus improve the test accuracy.

[0112] If the service interface is determined to be of method type and the scenario application is consumer (i.e., request-reply execution logic) according to the service information, the function is a request response function, which takes the SOME / IP data object as an input parameter and contains the logic of returning the expected value to the request according to the SOME / IP data object. The request response function is to execute the request response function based on the response signal after receiving the response signal sent by the tested end, so as to send the expected test signal corresponding to the response signal to the tested end for subsequent testing.

[0113] If the service interface is determined to be of method type and the scenario application is porvider (i.e., server-side execution logic) based on the service information, the function is a request to send statement function, which uses the SOME / IP data object as an input parameter to make a request, and is based on the logic of executing the next node after the scenario receives the request. The request to send statement function is to determine a new test function and a new test signal corresponding to the new SOME / IP data object based on the test result after receiving the test result sent by the tested end, and then send a new test signal to the tested end based on the new test function for continuous testing. The request to send statement function is to make related function requests and perform corresponding functions when running test cases.

[0114] In this application, the test case script language is an executable programming language, such as the commonly used Python, Java, etc. When the test case script is generated, the test functions of all the test cases corresponding to the call sequence will be registered in the service simulation layer. When there is a corresponding request, the service simulation layer will manage and execute the test function corresponding to the call sequence group, and input the SOME / IP data object as a parameter. According to the order of each action node of the call sequence group and the request timestamp, based on the test assertion function, it is judged whether the time sequence (that is, the execution order) of the call sequence group meets the assertion internally to determine whether the node execution order of the call sequence group is reasonable.

[0115] In addition, the selection node calls the service interface to obtain data and service status from the outside, so after the test case script is generated, it needs to actively send data that meets the requirements during operation (different from the passive reception of the action node). In the SOME / IP protocol, as a service simulation party, the way to actively provide service status and data is method and event. If the method is provided as method, its calling method is Client / Server mode (that is, request response mode), which is the same as the action node and can wait for requests for passive triggering. When the method is event, its calling method is publisher / receiver mode (that is, publishing and receiving mode). When the test case is generated, it is necessary to set the conditional value for the selection node in the service simulation layer, and provide a sending cycle so that the service simulation layer can actively send test signals at a certain period.

[0116] In this way, compared with the prior art, in the SIL environment, the mature SOME / IP protocol stack is usually used to directly write interface-level test cases, but due to the complex scenario application logic and the large number of calling services, the test engineer needs to manually sort out and write according to the scenario definition document and the vehicle-mounted scenario application logic. In this application, by converting the scenario definition document into a node network structure, the scenario logic is verified for logical conflicts, dead loops, interface definitions, etc., and finally a test case script based on the service interface is generated to achieve automated testing in the SIL environment and the HIL environment.

[0117] In addition, the implementation method of the present application generates test case scripts based on the standardized service interface (i.e., SOME / IP definition document), and can adapt to the SIL / HIL test environments by switching the underlying application of the test system, greatly reducing the test cycle and manpower investment.

[0118] Therefore, in the implementation method of the present application, after the test case layer generates a test case, by executing the test case (for example, the first test case), the test function corresponding to the test case (for example, the first test function) will be registered to the service simulation layer. The service simulation layer determines the test signal corresponding to the test function according to the test environment, and sends the test signal to the bus driver layer.

[0119] Next, taking the hardware-in-the-loop test environment as an example, a test signal (ie, the first test signal) corresponding to the first test function is generated for the service simulation layer and sent to the bus driver layer. The bus driver layer explains in detail the technical content of the corresponding processing of the tested end according to the first test signal.

[0120] In one implementation of the present application, when the test environment is a hardware-in-the-loop test environment, the service simulation layer determines a first test signal corresponding to a first test function, including: the service simulation layer determines a service-oriented test signal corresponding to the first test function, and determines a first mapping relationship between a logical conversion function, a service-oriented test signal, and a signal-oriented test signal, determines a logical conversion function corresponding to the service-oriented test signal according to the first mapping relationship, and converts the service-oriented test signal into a signal-oriented test signal based on the logical conversion function corresponding to the service-oriented test signal to obtain a first test signal.

[0121] In one implementation of the present application, the first mapping relationship is determined by the service simulation layer in the following manner: determine a signal-to-service logic table and a signal-oriented signal definition document, generate a service-to-signal logic relationship table based on the signal-to-service logic table and the signal-oriented signal definition document, and determine the first mapping relationship between the logic conversion function, the service-oriented test signal, and the signal-oriented test signal based on the service-to-signal logic relationship table.

[0122] For example, in one implementation, Figure 8 As shown, the service simulation layer includes a service-to-signal plug-in management module, a service abstraction module, and a registration management module, and the registration management module establishes communication connections with the test case layer and the bus driver layer interface respectively. Among them, if the test environment is a hardware-in-the-loop test environment, the service simulation layer includes the service-to-signal plug-in management module, the service abstraction module, and the registration management module to perform corresponding work.

[0123] The signal-to-service logic table and the CAN / LIN signal definition document (as an example of a signal-oriented signal definition document) are imported into the service-to-signal plug-in management module, and the service-to-signal plug-in management module generates a service-to-signal plug-in (i.e., a service-to-signal logic relationship table) according to the signal-to-service logic table and the CAN / LIN signal definition document, and then the service-to-signal plug-in management module performs version management on the service-to-signal logic relationship table and dynamically imports it. Among them, the service-to-signal logic plug-in is generally based on integer and floating-point arithmetic operations, which includes a logic conversion function for performing service-to-signal operations.

[0124] Next, the service-to-signal plug-in management module will dynamically import the dynamically imported logic conversion function into the service abstract module for logic mapping of the service and the signal. The service abstract module performs logic mapping of the service according to the service-to-signal logic plug-in, binds and maps the SOME / IP service interface definition, the service data structure, the simulation object of the related CAN / LIN signal and the imported logic conversion function (that is, obtains a first mapping relationship). When any one of the SOME / IP data object (as an example of an object-oriented test signal) or the CAN / LIN signal object (as an example of a signal-oriented test signal) changes, the associated object (that is, any one of a pair of SOMEIP data objects and CAN / LIN data objects with an associated relationship) can be automatically synchronized and updated through the corresponding logic conversion function. In this way, after determining the SOME / IP service object corresponding to the test signal, the CAN / LIN signal object corresponding to the SOME / IP service data object can be determined based on the first mapping relationship, and the SOME / IP service object can be converted into a CAN / LIN signal object based on the corresponding logic conversion function. In this way, the CAN / LIN signal test of the vehicle ECU hardware corresponding to the hardware-in-the-loop test environment is realized.

[0125] Therefore, compared with the existing method of using mature simulation tools (such as CANoe) in a HIL environment to write test case scripts with CAN / LIN bus signals as input and output, as the vehicle model baseline changes, test engineers need to re-sort out the logical relationship between functions, services and bus signals. The implementation method of this application automatically generates a service interface plug-in (that is, a service-to-signal logical relationship table) by reading and parsing the service and signal logical relationship table. Test engineers only need to write test cases for the service interface layer according to scenario requirements, without having to write test cases for the bus signal layer, and without having to worry about possible signal changes in different vehicle models. In this way, the generated test cases can be used in both HIL and SIL environments, without having to generate test cases separately, making test case generation more efficient.

[0126] Furthermore, the generated first mapping relationship will be transferred to the registration management module by the service abstraction module. Fig. 9 As shown, in the registration management module, the callback function containing the registration management logic is connected to the associated object and the bus driver layer interface to form a complete service conversion data channel.

[0127] Exemplarily, the test case layer registers test functions such as periodic sending functions and / or request sending functions to the service association object of the registration management module, the service association object determines the SOME / IP data object corresponding to the test function (as an example of a service-oriented test signal), and writes or modifies the SOME / IP data object in the test case, triggers the associated CAN / LIN signal based on the logical conversion function in the first mapping relationship (as an example of the first test signal), and sends the CAN / LIN signal to the bus driver layer.

[0128] It should be noted that for the periodic sending function and the request sending function, the conversion logic of the service-related object is to determine the SOME / IP data object corresponding to the test function, and convert the SOME / IP data object into a CAN / LIN signal object based on the corresponding logic conversion function to obtain the first test signal. For the test assertion function and the request response function, because the tested end needs to actively respond, the received test result is required. For example, the test result is a CAN / LIN signal object. The conversion logic of the service-related object is to convert the CAN / LIN signal object into a SOME / IP data object based on the corresponding logic conversion function.

[0129] Therefore, in this application, in the HIL test environment, when the test case layer determines that the SOME / IP data object needs to be called or the SOME / IP data object needs to be modified (that is, the SOME / IP interface is called) after analyzing the scenario definition document, the service association object will modify the CAN / LIN data object through the logical conversion function associated with the SOME / IP data object, and then pass the changed CAN / LIN data object to the bus driver layer through the registration management module, and send the CAN / LIN signal object (as an example of the first test signal) to the ECU under test through the bus interface device on the real CAN / LIN bus.

[0130] That is, in this implementation, the logic conversion function is used to perform logic conversion between the SOME / IP data object and the corresponding CAN / LIN data object. For example, when the A parameter of the CAN / LIN data object is equal to 1, the B parameter of the corresponding SOME / IP data object needs to be equal to 2, or the conditional selection or formula of the B parameter of the SOME / IP data object = the A parameter of the CAN / LIN data object * 20. That is, the logic conversion function is used to convert the CAN / LIN signal sent by the received bus driver layer into the corresponding SOME / IP signal, or to convert the determined SOME / IP signal into the corresponding CAN / LIN signal.

[0131] That is, in the implementation of the present application, the registration management module sends the CAN / LIN signal-oriented test signal (ie, the first test signal) to the bus driver layer, and the bus driver layer performs corresponding processing on the tested end according to the first test signal.

[0132] In one implementation of the present application, the bus driver layer performs corresponding processing on the tested end according to the first test signal, including: the bus driver layer sends the first test signal to the tested end, the tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer.

[0133] Exemplarily, the tested end generates a test result corresponding to the first test signal according to the first test signal, the test result includes a second test signal in response to the first test signal, and the second test signal is sent to the bus driver layer.

[0134] Furthermore, in an implementation of the present application, when the test environment is a hardware-in-the-loop test environment, the tested end is an electronic control unit under test, and the electronic control unit under test includes an underlying driver, middleware, and a vehicle-mounted scenario application. The tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer, including: the underlying driver converts the first test signal and sends it to the middleware, the middleware generates a service notification message according to the converted first test signal, and sends it to the vehicle-mounted scenario application, the vehicle-mounted scenario application generates a corresponding second test signal according to the service notification message, and sends the second test signal to the middleware, the middleware converts the second test signal and sends it to the underlying driver, and the underlying driver sends the converted second test signal to the bus driver layer.

[0135] For example, Fig.10 It is shown that in the implementation of this application, the bus driver layer includes a function registration management module, a serialization processing module, a signal processing module, and a vehicle control processing module. In the HIL environment, the function registration management module, signal processing module, and vehicle control processing module included in the bus driver layer work, and rely on the CAN / LIN protocol stack and hardware bus driver to establish a connection with the ECU under test.

[0136] Of course, the connection between the bus driver layer and the ECU under test can be implemented using a general technology stack or other methods.

[0137] The function registration management module is responsible for connecting to the registration management module of the service simulation layer to receive the first test signal, and encapsulating the underlying communication logic via a layer of standardized callback interface.

[0138] Exemplarily, when a CAN / LIN data object (i.e., a CAN / LIN signal object) (as an example of a first test signal) is transmitted to the function registration management module of the bus driver layer, the function registration management module will distribute the CAN / LIN data object to the signal processing module, the signal processing module will convert the CAN / LIN data object into a transmittable network message, and then pass it to the CAN / LIN protocol stack, and finally send it to the underlying driver of the ECU under test through the hardware bus driver. The underlying driver converts the CAN / LIN data object into a service and sends it to the middleware. The middleware generates an execution instruction (i.e., a service notification message) based on the converted CAN / LIN data object and sends it to the vehicle-mounted scenario application. The vehicle-mounted scenario application performs corresponding operations according to the execution instruction and generates an execution result (as an example of a second test signal), and sends the execution result to the middleware. The middleware converts the second test signal to generate a message recognizable by the underlying driver. The underlying driver then sends the converted second test signal to the signal processing module via the CAN / LIN protocol stack. The signal processing module then sends the second test signal to the function registration management module for subsequent processing via the function registration management module.

[0139] Furthermore, in one implementation of the present application, there may be special logic for encryption and verification when the CAN / LIN data object is sent. The CAN / LIN data frame with this logic will first be processed by the vehicle control processing module and then decide whether to return to the upper-level signal processing module for signal processing.

[0140] In one implementation of the present application, the generated second test signal needs to be sent to the service simulation layer via the bus driver layer for subsequent test verification or subsequent continuous testing. Fig.11 The vehicle testing method provided by the implementation of the present application also includes the following steps:

[0141] S150: The bus driver layer sends the second test signal to the service simulation layer.

[0142] Exemplarily, when receiving the second test signal, the function registration management module sends the second test signal to the function registration module of the service simulation layer.

[0143] S160, the service simulation layer determines the corresponding first test callback function according to the preset function callback logic and the second test signal, obtains the third test signal according to the second test signal, and sends the third test signal to the test case layer based on the first test callback function.

[0144] Exemplarily, the function registration module determines a first test callback function according to a preset function callback logic and a signal type of the second test signal (for example, a CAN / LIN data object), determines a logic conversion function of the second test signal through a first mapping relationship, converts the second test signal (for example, a CAN / LIN data object) into a third test signal (for example, a SOME / IP data object) based on the logic conversion function, and sends the third test signal to the test case layer based on the first test callback function.

[0145] like Fig. 9 The callback logic is as follows: if the received second test signal is a vehicle control frame, the vehicle CAN / LIN signal is modified according to the vehicle control frame, and the SOME / IP data object corresponding to the CAN / LIN signal is updated based on the determined logic conversion function, and the SOME / IP data object is sent to the test case layer as a function input parameter and placed in the test assertion function or in the request response function.

[0146] Furthermore, the callback logic is that if the received second test signal is a CAN / LIN signal, the CAN / LIN signal currently being sent by the registration management module is modified, and based on the determined logic conversion function, the SOME / IP data object corresponding to the CAN / LIN signal is triggered to be updated, and the SOME / IP data object is sent to the test case layer as a function input parameter into the test assertion function or into the request response function. Moreover, based on the modified CAN / LIN signal, the associated CAN / LIN signal is triggered and sent to the bus driver layer, so that the bus driver layer performs corresponding processing on the tested end based on the associated CAN / LIN signal.

[0147] That is, the test does not just send the test signal once, but triggers the sending of associated test signals based on the received test results, so that the tested end generates a test result based on the associated test signal.

[0148] S170, the test case layer determines a test result according to the third test signal and / or determines a second test case according to the third test signal.

[0149] Exemplarily, the test case layer verifies the test results based on the test assertion function. Assertions are in the form of determining whether a parameter is equal to N. The content of the assertion is determined according to the scenario definition document. For example, if the scenario definition document defines that the air conditioner should be OFF in the scenario, then the assertion determines that the status parameter of the air conditioner status service interface Aircondition is OFF. In other words, it determines whether the value returned by the test is the expected value.

[0150] Or the test case layer verifies whether the received test result is the expected value based on the request response function, and generates a new test case based on the test result (as an example of the second test case) to run the new test case, generate a new test function, and perform subsequent tests based on the new test function and the new test signal. In this way, the vehicle can be tested continuously without manual triggering each time, making the test automated.

[0151] Or directly generate a new test case (as an example of the second test case) based on the test results, run the new test case, generate a new test function (as an example of the second test function), and perform subsequent tests based on the new test function and the new test signal.

[0152] Therefore, in this application, when a relevant data frame (such as a second signal-oriented test signal such as CAN / LIN) is transmitted back from the tested end to the bus driver layer, the bus driver layer will perform the second test signal return according to Fig. 9 The callback logic shown converts the CAN / LIN signal-oriented test signal into the SOME / IP service-oriented test signal, and automatically updates the SOME / IP data object (i.e., obtains the SOME / IP service-oriented third test signal). The upper-layer test case can make assertions based on the SOME / IP data object to determine whether the test result is correct, etc.

[0153] Next, taking the test environment as a software-in-the-loop test environment as an example, a test signal (that is, the first test signal) corresponding to the test function is generated for the service simulation layer and sent to the bus driver layer. The bus driver layer explains in detail the technical content of the corresponding processing of the tested end according to the first test signal.

[0154] When the test environment is a software-in-the-loop test environment, the service simulation layer determines the first test signal corresponding to the test function, including: the service simulation layer determines a service-oriented signal definition document, determines the service-oriented test signal according to the service-oriented signal definition document, and the service simulation layer determines the service-oriented test signal corresponding to the test function as the first test signal.

[0155] For example, in one implementation, Fig.12 As shown, if the test environment is a software-in-the-loop test environment, the service abstraction module and the registration management module included in the service simulation layer perform corresponding work.

[0156] Among them, the service abstraction layer generates a SOME / IP data object (that is, a service-oriented test signal) according to the imported SOME / IP definition document (as a service-oriented signal definition document), and transmits the SOME / IP data object to the registration management module. In the registration management module, identifiers such as the service ID of the SOMEIP protocol are associated with the test function transmitted from the test case layer to facilitate obtaining the first test signal corresponding to the test function, register the SOMEIP data object and transmit it to the bus driver layer, and facilitate returning the test result to the test case layer based on the callback function after the test result is generated.

[0157] Therefore, the vehicle testing method provided by the present application can switch freely between the SIL environment and the HIL environment mainly based on the encapsulation of the service simulation layer. In the SIL environment, only part of the logic of the service abstraction module and the registration management module is enabled, and the determined SOME / IP data object is passed to the bus driver layer to realize the vehicle test based on the virtual machine in the SIL environment. In the HIL environment, the service-to-signal plug-in management module, the service abstraction module, and the registration management module are all enabled. The registration management module obtains the first mapping relationship, performs logical management based on the first mapping relationship, determines the CAN / LIN data object corresponding to the SOME / IP data object, and passes the CAN / LIN data object to the bus driver layer to realize the vehicle test based on the ECU under test in the HIL environment.

[0158] Furthermore, the test functions generated by the test case layer and the SOME / IP data objects generated by the service abstraction module will be passed to the registration management module, the registration management module determines the service-oriented test signals (i.e., the SOME / IP data objects) corresponding to the test functions, and passes the SOME / IP data objects to the bus driver layer, which passes them to the virtual image of the module under test through the virtual bridge.

[0159] Therefore, in the SIL environment, the vehicle control frame and CAN / LIN signal related logic will not be involved. The SOME / IP data object is directly passed to the bus driver layer when sending. The bus driver layer passes it to the virtual image of the module under test through the virtual bridge. Other callback logic is the same as in the HIL environment.

[0160] In one implementation of the present application, the bus driver layer performs corresponding processing on the tested end according to the first test signal, including: the bus driver layer sends the first test signal to the tested end, the tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer.

[0161] Exemplarily, the tested end generates a test result corresponding to the first test signal according to the first test signal, the test result includes a second test signal in response to the first test signal, and the second test signal is sent to the bus driver layer.

[0162] Furthermore, in one implementation of the present application, when the test environment is a software-in-the-loop test environment, the tested end is a virtual machine, and the virtual machine includes a virtual image and a vehicle-mounted scenario application. The tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer, including: the virtual image generates a service notification message according to the first test signal, sends it to the vehicle-mounted scenario application, the vehicle-mounted scenario application generates a corresponding second test signal according to the service notification message, sends the second test signal to the virtual image, and the virtual image sends the second test signal to the bus driver layer.

[0163] For example, Fig.10 As shown, in the implementation of the present application, in the SIL environment, the bus driver layer includes a function registration management module and a serialization processing module to work, and the bus driver layer also needs to rely on the SOME / IP protocol stack and related virtual bridges to establish a connection with the virtual machine.

[0164] Of course, the connection between the bus driver layer and the virtual machine can be implemented using a general technology stack or other methods.

[0165] Furthermore, when a SOME / IP data object (as an example of a first test signal) is transmitted to the function registration management module of the bus driver layer, the function registration management module will distribute the SOME / IP data object to the serialization processing module, the serialization processing module will convert the SOME / IP data object into a transmittable network message, and then transmit it to the SOME / IP protocol stack, and finally send the message to the virtual image module of the software under test in the virtual machine through the virtual bridge (i.e., the virtual network card), the virtual image generates an execution instruction (i.e., a service notification message) according to the converted SOME / IP data object, and sends it to the vehicle-mounted scenario application, the vehicle-mounted scenario application performs the corresponding operation according to the execution instruction, and generates an execution result, i.e., a new SOME / IP data object (as an example of a second test signal), and sends the execution result to the virtual image, the delicate image converts the second test signal to generate a message of the virtual bridge, the virtual bridge then sends the converted second test signal to the serialization processing module via the SOME / IP protocol stack, the serialization processing module then sends the second test signal to the function registration management module, and the function registration management module performs subsequent processing.

[0166] In one implementation of the present application, the generated second test signal needs to be sent to the service simulation layer via the bus driver layer for subsequent test verification or subsequent continuous testing. Fig.13 As shown, when the test environment is a software-in-the-loop test environment, the vehicle testing method further includes:

[0167] S150', the bus driver layer sends the second test signal to the service simulation layer.

[0168] Exemplarily, when receiving the second test signal, the function registration management module sends the second test signal to the function registration module of the service simulation layer.

[0169] S160', the service simulation layer determines a corresponding second test callback function according to the preset function callback logic and the second test signal, and sends the second test signal to the test case layer based on the second test callback function.

[0170] Exemplarily, the function registration module determines the second test callback function according to the preset function callback logic and the signal type of the second test signal (eg, SOME / IP data object), and sends the second test signal to the test case layer based on the second test callback function.

[0171] like Fig. 9 As shown, the callback logic is that if the received second test signal is a SOME / IP data object, the SOME / IP data object currently being sent by the registration management module is modified, and the SOME / IP data object is sent to the test case layer as a function input parameter into the test assertion function or into the request response function.

[0172] S170', the test case layer determines a test result according to the second test signal and / or determines a second test case according to the second test signal.

[0173] Exemplarily, the test case layer performs test result verification based on the test assertion function.

[0174] Or the test case layer verifies whether the received test result is the expected value based on the request response function, and generates a new test case based on the test result (as an example of the second test case) to run the new test case, generate a new test function, and perform subsequent tests based on the new test function and the new test signal. In this way, the vehicle can be tested continuously without manual triggering each time, making the test automated.

[0175] Alternatively, a new test case is directly generated based on the test result (as an example of a second test case), so as to run the new test case, generate a new test function, and perform subsequent tests based on the new test function and the new test signal.

[0176] It should be noted that, in the implementation of the present application, the first test signal corresponding to the test function can be determined based on the scenario requirements in the scenario definition document or the attributes of the SOME / IP data object in the SOME / IP definition document.

[0177] Therefore, the vehicle testing method and system provided by the implementation of the present application are actually a testing method and system for in-vehicle intelligent scenarios based on SOME / IP, which meets the requirement that existing testing methods cannot support in-vehicle intelligent scenario testing in SIL environment / HIL environment at the same time. For example, by running test cases, CAN / LIN data objects in HIL environment can be generated to test the in-vehicle scenario application in different scenarios in the tested ECU, and SOME / IP data objects in SIL environment can be generated to test the in-vehicle scenario application in different scenarios in the virtual image.

[0178] Moreover, in the HIL environment, the relationship between the SOME / IP services and CAN / LIN signals of each model and baseline is automatically loaded and generated directly through the signal-to-service logic table, eliminating the need for test engineers to manually determine and verify the relationship between signals and services, as well as the process of writing test code based on the sorted out SOME / IP data objects.

[0179] Furthermore, in the application architecture using the scenario service definition document, the corresponding test cases can be directly verified and generated, which improves the efficiency of the test, expands the scope of the test, can fully cover each service call logic branch, and improves the comprehensiveness of the test. And through the highly encapsulated test system architecture, the test cases can be covered on a platform basis at the application level, greatly shortening the test cycle in the current platform-based agile development of new energy vehicles. Moreover, the layered architecture approach can flexibly replace different underlying protocol stacks and hardware device drivers, and can support the replacement of hardware devices without affecting the upper-level test functions to reduce the cost of testing, making it more practical. And through the innovative introduction of a logical node network in the vehicle-mounted scenario test, the test input can be made looser, and the service scenario logic for asynchronous calls can be expanded and optimized, making the generated test cases more comprehensive.

[0180] See also Fig.14 In one implementation of the present application, a vehicle testing method in a HIL environment includes the following steps:

[0181] 1. The test case layer generates test case scripts based on the scenario service definition file and the SOME / IP definition document (as an example of a service-oriented signal definition file).

[0182] 2. The service simulation layer generates a service-to-signal logic relationship according to the signal-to-service logic table, and generates a logic mapping relationship (ie, a first mapping relationship) and a SOME / IP service object.

[0183] 3. The test engineer selects test cases and related configurations according to test requirements on the test interface provided by the test framework layer to determine the test environment and test cases (ie, the first test case).

[0184] 4. The test framework layer calls the test case layer to start executing the test case.

[0185] 5. The test case layer runs the test case and determines the test function to register the function with the service simulation layer (ie, sends the test function to the service simulation layer).

[0186] 6. The service simulation layer determines the corresponding test signal (ie, the first test signal) according to the test function to register the function with the bus driver layer (ie, send the test signal to the bus driver layer).

[0187] 7. The bus driver layer sends a CAN / LIN signal (ie, a first signal-oriented test signal, ie, the aforementioned CAN / LIN data object) to the underlying driver O / S based on the bus interface device.

[0188] 8. The underlying driver O / S converts the CAN / LIN signal into a network message and sends it to the middleware.

[0189] 9. The middleware generates service communication messages based on network messages and sends them to the in-vehicle scenario application.

[0190] 10. The in-vehicle scenario application generates a corresponding service (ie, a signal-oriented second test signal) according to the service notification message and sends it to the middleware.

[0191] 11. The middleware converts the second test signal into a network message and sends it to the underlying driver O / S.

[0192] 12. The bottom-layer driver O / S sends the second test signal to the bus driver layer based on the bus interface device.

[0193] 13. The bus driver layer performs CAN / LIN data object callback and sends the CAN / LIN data object to the service simulation layer.

[0194] 14. The service simulation layer triggers the corresponding SOME / IP service object (ie, triggers the update of the corresponding SOME / IP data object), and sends the SOME / IP data object to the test case layer based on the relevant callback function.

[0195] 15. The test case layer determines whether the test logic is correct and / or marks the test results based on the SOME / IP data objects sent back.

[0196] It should be noted that the specific process of the above-mentioned vehicle testing method in the HIL environment can refer to the specific contents of the aforementioned steps S110 to S140, and steps S150 to S170.

[0197] See also Fig.15 In one implementation of the present application, a vehicle testing method in a SIL environment includes the following steps:

[0198] 1. The test case layer generates test case scripts based on the scenario service definition file and the SOME / IP definition document (as an example of a service-oriented signal definition file).

[0199] 2. The service simulation layer generates SOME / IP service objects (ie, SOME / IP data objects) according to the SOME / IP definition document.

[0200] 3. The test engineer selects test cases and related configurations according to test requirements on the test interface provided by the test framework layer to determine the test environment and test cases (ie, the first test case).

[0201] 4. The test framework layer calls the test case layer to start executing the test case.

[0202] 5. The test case layer runs the test case and determines the test function to register the function with the service simulation layer (ie, sends the test function to the service simulation layer).

[0203] 6. The service simulation layer determines the corresponding test signal (ie, the first test signal) according to the test function to register the function with the bus driver layer (ie, send the test signal to the bus driver layer).

[0204] 7. The bus driver layer converts the SOME / IP signal (ie, the first service-oriented test signal, ie, the aforementioned SOME / IP data object) into a network message (eg, Ethernet message) based on the virtual network card and sends the Ethernet message to the virtual mirror.

[0205] 8. The virtual image generates a service communication message based on the Ethernet message and sends it to the in-vehicle scenario application.

[0206] 9. The in-vehicle scenario application generates a corresponding service (ie, a service-oriented second test signal) according to the service notification message and sends it to the virtual image.

[0207] 11. The virtual mirror converts the second test signal into an Ethernet message and sends it to the bus driver layer through the virtual network card.

[0208] 13. The bus driver layer performs a callback of the SOME / IP data object and sends the SOME / IP data object to the service simulation layer.

[0209] 14. The service simulation layer triggers the corresponding SOME / IP service object's callback function to send the ME / IP data object to the test case layer.

[0210] 15. The test case layer determines whether the test logic is correct and / or marks the test results based on the SOME / IP data objects sent back.

[0211] It should be noted that the specific process of the above vehicle testing method in the SIL environment can refer to the specific contents of the above steps S110 to S140, and steps S150' to S170'.

[0212] Furthermore, the implementation of the present application also discloses a vehicle testing method, which is applied to a test end, and the test end includes a test framework layer, a test case layer, a service simulation layer and a bus driver layer. The method includes: the test framework layer determines the target test configuration information according to the user's configuration operation on the test configuration information based on the test environment requirements, the target test configuration information includes a first test case, and calls the test case layer to execute the first test case, and the test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment; the test case layer generates a first test function according to the first test case, and sends it to the service simulation layer; the service simulation layer determines a first test signal corresponding to the first test function, and sends the first test signal to the bus driver layer; the bus driver layer performs corresponding processing on the tested end according to the first test signal.

[0213] Furthermore, the implementation of the present application also discloses a vehicle testing method, which is applied to the tested end, and the tested end receives a first test signal sent by a bus driver layer included in the test end, so as to perform corresponding processing according to the first test signal, wherein the first test signal is determined by the service simulation layer included in the test end as a first test signal corresponding to a first test function, and the first test signal is sent to the bus driver layer, and the first test function is generated by the test case layer included in the test end according to the first test case. The first test function is sent to the service simulation layer, and the first test case is determined by the test framework layer included in the test end according to the user's configuration operation on the test configuration information based on the test environment requirements. The target test configuration information includes a first test case, and the test case layer is called to execute the first test case. The test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment.

[0214] The test end of the implementation method of the present application can be deployed on an electronic device.

[0215] See also Fig.16 , Fig.16The figure shows a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig.15 As shown, the electronic device may include: a transceiver 121 , a processor 122 , and a memory 123 .

[0216] The processor 122 executes the computer execution instructions stored in the memory, so that the processor 122 executes the technical solution of the vehicle test method executed by the test end in the above embodiment. The processor 122 can be a general-purpose processor, including a central processing unit CPU, a network processor (NP), etc.; it can also be a digital data processor DSP, an application-specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components.

[0217] The memory 123 is connected to the processor 122 via a system bus and completes communication between them. The memory 123 is used to store computer program instructions.

[0218] By way of example and not limitation, the memory 123 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 123 may include a removable or non-removable (or fixed) medium. Where appropriate, the memory 123 may be inside or outside the integrated gateway device. In a particular embodiment, the memory 123 is a non-volatile solid-state memory. In a particular embodiment, the memory 123 includes a read-only memory (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or a flash memory, or a combination of two or more of these.

[0219] The transceiver 121 may be used to obtain tasks to be executed and configuration information of the tasks to be executed.

[0220] The system bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The transceiver is used to realize the communication between the database access device and other computers (such as clients, read-write libraries, and read-only libraries). The memory may include random access memory (RAM) and may also include non-volatile memory.

[0221] An embodiment of the present application also provides a chip for running instructions, which is used to execute the technical solution of the vehicle testing method in the above embodiment.

[0222] An embodiment of the present application also provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on a processor of an electronic device, the processor of the electronic device executes the technical solution of the vehicle testing method of the above embodiment.

[0223] In some possible implementations, various aspects of the method provided in the present application may also be implemented in the form of a program product, which includes a program code. When the program product is run on a processor of an electronic device, the program code is used to enable the processor of the electronic device to execute the steps of the method according to various exemplary implementations of the present application described above in this specification. For example, the electronic device may execute the vehicle testing method described in the embodiments of the present application.

[0224] The program product may employ any combination of one or more readable media. The readable medium may be a readable data medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0225] The implementation method of the present application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When at least one processor executes the computer program, the technical solution of the vehicle testing method in the above embodiment can be implemented.

[0226] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable information processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable information processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0227] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable information processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0228] These computer program instructions can also be loaded onto a computer or other programmable information processing device so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0229] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary technical means in the art that are not disclosed in the present application.

[0230] It should be noted that, in addition to the implementation methods of the present invention described in the above-mentioned specific embodiments, those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. Although the description of the present invention is introduced in conjunction with the preferred embodiment, this does not mean that the features of this invention are limited to this implementation method. On the contrary, the purpose of introducing the invention in conjunction with the implementation method is to cover other options or modifications that may be extended based on the claims of the present invention. In order to provide a deep understanding of the present invention, the above description contains many specific details, and the present invention can also be implemented without using these details. In addition, in order to avoid confusion or blurring the focus of the present invention, some specific details will be omitted in the description. It should be noted that the embodiments of the present invention and the features in the embodiments can be combined with each other without conflict.

[0231] It should be noted that in this specification, similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0232] The terms “first”, “second”, etc. are only used for distinguishing descriptions and should not be understood as indicating or implying relative importance.

[0233] Although the present invention has been illustrated and described with reference to certain preferred embodiments of the present invention, it should be understood by those skilled in the art that the above is a further detailed description of the present invention in conjunction with specific embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. Those skilled in the art may make various changes in form and details, including making several simple deductions or substitutions, without departing from the spirit and scope of the present invention.

Claims

1. A vehicle testing method, characterized in that: Applied to a vehicle test system, the vehicle test system includes a test end and a tested end, the test end includes a test framework layer, a test case layer, a service simulation layer and a bus driver layer, and the method includes: The test framework layer determines target test configuration information according to a configuration operation of the test configuration information by the user based on the test environment requirements, the target test configuration information includes a first test case, and calls the test case layer to execute the first test case, the test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment; The test case layer generates a first test function according to the first test case, and sends it to the service simulation layer; The service simulation layer determines a first test signal corresponding to the first test function, and sends the first test signal to the bus driver layer; The bus driving layer performs corresponding processing on the tested end according to the first test signal.

2. The vehicle testing method according to claim 1, characterized in that: The bus driving layer performs corresponding processing on the tested end according to the first test signal, including: The bus driving layer sends the first test signal to the tested end; The tested end performs corresponding processing according to the first test signal to generate a second test signal, and sends the second test signal to the bus driver layer.

3. The vehicle testing method according to claim 2, characterized in that: In the case where the test environment is the hardware-in-the-loop test environment, the method further includes: The bus driver layer sends the second test signal to the service simulation layer; The service simulation layer determines the corresponding first test callback function according to the preset function callback logic and the second test signal, obtains a third test signal according to the second test signal, and sends the third test signal to the test case layer based on the first test callback function; The test case layer determines a test result according to the third test signal and / or determines a second test case according to the third test signal.

4. The vehicle testing method according to claim 2, characterized in that: In the case where the test environment is the software-in-the-loop test environment, the method further includes: The bus driver layer sends the second test signal to the service simulation layer; The service simulation layer determines a corresponding second test callback function according to a preset function callback logic and the second test signal, and sends the second test signal to the test case layer based on the second test callback function; The test case layer determines a test result according to the second test signal and / or determines a second test case according to the second test signal.

5. The vehicle testing method according to any one of claims 1 to 4, characterized in that: In a case where the test environment is the hardware-in-the-loop test environment, the service simulation layer determines a first test signal corresponding to the first test function, including: The service simulation layer determines a service-oriented test signal corresponding to the first test function, and determines a first mapping relationship between a logic conversion function, a service-oriented test signal, and a signal-oriented test signal; The service simulation layer determines the logic conversion function corresponding to the service-oriented test signal according to the first mapping relationship, and converts the service-oriented test signal into a signal-oriented test signal based on the logic conversion function corresponding to the service-oriented test signal to obtain the first test signal.

6. The vehicle testing method according to claim 5, characterized in that: The first mapping relationship is determined by the service simulation layer in the following manner: Determine a signal-to-service logic table and a signal-oriented signal definition document, and generate a service-to-signal logic relationship table according to the signal-to-service logic table and the signal-oriented signal definition document; The first mapping relationship among the logic conversion function, the service-oriented test signal, and the signal-oriented test signal is determined according to the service-to-signal logic relationship table.

7. The vehicle testing method according to any one of claims 1 to 6, characterized in that: In a case where the test environment is the software-in-the-loop test environment, the service simulation layer determines a first test signal corresponding to the first test function, including: The service simulation layer determines a service-oriented signal definition document, and determines a service-oriented test signal according to the service-oriented signal definition document; The service simulation layer determines the service-oriented test signal corresponding to the first test function as the first test signal.

8. The vehicle testing method according to any one of claims 1 to 7, characterized in that: The test cases included in the test case layer are generated by the test case layer in the following manner: Determine scene service definition information, and generate node network information according to the scene service definition information; Determine a service-oriented signal definition document, and perform verification processing on the node network information according to the service-oriented signal definition document to obtain a verification result; If the verification result is that the verification is passed, generating at least one call sequence according to the node network information; The test case is generated according to the calling sequence.

9. The vehicle testing method according to claim 8, characterized in that: The test case layer verifies the node network information according to the service-oriented signal definition document to obtain a verification result, including: The test case layer determines the node information of each node included in the node network information according to the service-oriented signal definition document, performs a first verification process on the node information to obtain a first verification result, and determines the node type of each node when the first verification result is a verification pass; For a node whose node type is a self-loop node, the test case layer performs pruning processing on the self-loop node and determines the self-loop node as a waiting node; For nodes whose node types are other than self-loop nodes, the test case layer determines the starting node and establishes a service status table, stores the node information of each node in the service status table, and performs a depth-first traversal based on the starting node to perform a second verification process on each node to obtain a second verification result, wherein, if the last associated node of the node is determined to be an end node based on the depth-first traversal, then the second verification result is determined to be a passed verification, if the last associated node of the node is determined to be a conditional node based on the depth-first traversal, and it is determined according to the service status table that the node cannot jump to the conditional node, and there is no other node to jump to, then the second verification result is determined to be a failed verification, and the conditional node is the self-loop node or the conditional judgment node; The verification result for the node network information is obtained according to the first verification result and the second verification result.

10. The vehicle testing method according to claim 2, characterized in that: In the case where the test environment is the hardware-in-the-loop test environment, the tested end is an electronic control unit under test, and the electronic control unit under test includes a bottom-level driver, middleware, and an in-vehicle scenario application, then the tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer, including: The bottom layer driver converts the first test signal and sends it to the middleware; The middleware generates a service notification message according to the converted first test signal, and sends the message to the in-vehicle scenario application; The in-vehicle scenario application generates the corresponding second test signal according to the service notification message, and sends the second test signal to the middleware; The middleware converts the second test signal and sends it to the bottom layer driver; The bottom layer driver sends the converted second test signal to the bus driver layer.

11. The vehicle testing method according to claim 2, characterized in that: In the case where the test environment is the software-in-the-loop test environment, the tested end is a virtual machine, and the virtual machine includes a virtual image and an in-vehicle scenario application, then the tested end performs corresponding processing according to the first test signal, generates a second test signal, and sends the second test signal to the bus driver layer, including: The virtual mirror generates a service notification message according to the first test signal and sends it to the in-vehicle scenario application; The in-vehicle scenario application generates the corresponding second test signal according to the service notification message, and sends the second test signal to the virtual mirror; The virtual image sends the second test signal to the bus driver layer.

12. A vehicle testing system, characterized in that: The vehicle testing system includes a testing end and a tested end, wherein the testing end includes a testing framework layer, a testing case layer, a service simulation layer and a bus driver layer. The test framework layer is used to determine target test configuration information according to the configuration operation of the test configuration information by the user based on the test environment requirements, the target test configuration information includes a first test case, and calls the test case layer to execute the first test case, the test environment includes a hardware-in-the-loop test environment and a software-in-the-loop test environment; The test case layer is used to generate a first test function according to the first test case and send it to the service simulation layer; The service simulation layer is used to determine a first test signal corresponding to the first test function, and send the first test signal to the bus driver layer; The bus driving layer is used to perform corresponding processing on the tested end according to the first test signal.

13. An electronic device, characterized in that: The electronic device comprises the test terminal included in the vehicle test system according to claim 12.

Images