A vehicle-mounted SOA test device

Abstract

The utility model discloses a vehicle-mounted SOA test equipment relates to vehicle-mounted SOA test field. This vehicle-mounted SOA test equipment, including host computer, vehicle-mounted system A core, vehicle-mounted middleware layer and vehicle-mounted system M core, vehicle-mounted system A core is equipped with lower computer and association function module, vehicle-mounted middleware layer is used for realizing data forwarding and communication adaptation, and vehicle-mounted system M core is deployed with bottom layer architecture module, host computer and vehicle-mounted system A core realize data interaction, and vehicle-mounted system A core, vehicle-mounted middleware layer, vehicle-mounted system M core are connected in proper order and form data transmission path, and the inside of vehicle-mounted system A core realizes the interaction between modules through intercore communication framework. This vehicle-mounted SOA test equipment, through the CAN message processing module software simulation CAN data message of host computer, replaces CANOE, CDC and other hardware equipment, reduces hardware investment, supports no -code mode generation test case at the same time, reduces the technical requirement to test engineer, and saves manpower cost.

Description

Technical Field

[0001] This utility model relates to the field of vehicle-mounted SOA testing technology, specifically to a vehicle-mounted SOA testing device. Background Technology

[0002] In the field of automotive SOA (Service-Oriented Architecture) testing, existing technologies rely on CANOE devices to simulate CAN data, CDC devices to trigger scenarios, or mobile client operations. These technologies suffer from problems such as dependence on a large number of hardware devices, the need for test engineers to manually execute processes, long test cycles, and low coverage.

[0003] For example, the testing process requires the collaboration of multiple devices, and engineers need to verify SOA services one by one according to a fixed process. This not only increases the testing cost, but also makes it easy for tests to be missed due to manual operation. It is difficult to meet the complex testing requirements of SOA architecture, such as multi-domain controller interaction and performance evaluation (such as communication latency and bandwidth utilization). Utility Model Content

[0004] To address the shortcomings of existing technologies, this utility model provides an in-vehicle SOA testing device, which solves the problems of existing in-vehicle SOA testing relying on a large number of hardware devices, high manual operation costs, low testing efficiency, and long testing cycles.

[0005] To achieve the above objectives, this utility model provides the following technical solution: an in-vehicle SOA testing device, comprising a host computer, an in-vehicle system A core, an in-vehicle middleware layer, and an in-vehicle system M core; the in-vehicle system A core is equipped with a slave computer and associated functional modules; the in-vehicle middleware layer is used to realize data forwarding and communication adaptation; the in-vehicle system M core is deployed with underlying architecture modules; The host computer interacts with the vehicle system A core. The vehicle system A core, the vehicle middleware layer, and the vehicle system M core are connected in sequence to form a data transmission path. The vehicle system A core interacts with modules through an inter-core communication framework.

[0006] Preferably, the host computer is equipped with a test main control program and a network communication module, wherein the network communication module provides communication support for data interaction between the host computer and the vehicle system A core.

[0007] Preferably, the associated functional modules of the vehicle system A core include an atomic service module, a combined service module, an MCU proxy module, and an auxiliary system layer, wherein the atomic service module, the combined service module, and the MCU proxy module are all configured with an inter-core communication framework.

[0008] Preferably, the lower-level machine includes a test execution program, an in-vehicle service communication protocol, and a second CAN message processing module, wherein the test execution program is used to execute specific test procedures.

[0009] Preferably, the vehicle middleware layer includes a protocol forwarding module, a low-latency communication module, and a CAN bus. The protocol forwarding module enables the conversion and forwarding of data from different protocols.

[0010] Preferably, the underlying architecture module of the vehicle system M-core is an AUTOSAR architecture module, which provides underlying architecture support for the vehicle system.

[0011] Preferably, the host computer can encapsulate CAN data into a format suitable for A-core communication of the vehicle system and transmit it through the network communication module.

[0012] Preferably, the MCU agent module communicates with the atomic service module, the combined service module, the vehicle service communication protocol, the auxiliary system layer, and the AUTOSAR architecture module through an inter-core communication framework. The atomic service module and the combined service module can interact with the test executor, the auxiliary system layer, the protocol forwarding module, and the low-latency communication module based on the inter-core communication framework.

[0013] Preferably, the host computer can send test case scripts to the slave computer via the network communication module, which are then executed by the test execution program. The vehicle-mounted service communication protocol supports SOME / IP, DDS, and MQTT transmission protocols and is used for SOA service communication with the atomic service module, composite service module, protocol forwarding module, and network communication module.

[0014] Preferably, the low-latency communication module enables low-latency data transmission between the CAN bus and the protocol forwarding module.

[0015] Its beneficial effects are as follows: 1. This vehicle-mounted SOA testing equipment simulates CAN data messages through the CAN message processing module software on the host computer, replacing hardware devices such as CANOE and CDC, thus reducing hardware investment. It also supports no-code mode for generating test cases, lowering the technical requirements for test engineers and saving labor costs. The host computer can send test case scripts to the lower-level machine of the vehicle system's A-core via the network communication module, where the test execution program automatically executes them, achieving full automation of scenario testing, stress testing, and other processes, significantly shortening the testing cycle and enabling the completion of a large number of testing tasks in a short time. It supports testing of multiple protocols such as SOME / IP and DDS, and implements complete in-loop test logic through atomic service modules and composite service modules. Combined with assertion comparison and automatic message parsing, it ensures comprehensive test coverage and accurate results. Furthermore, test cases can be stored long-term, facilitating continuous testing and service change tracking. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram of the overall structure of this utility model.

[0018] In the diagram: 1. Host computer; 11. Test main control program; 12. Network communication module; 13. First CAN message processing module; 2. Vehicle system A core; 21. Lower computer; 211. Test execution program; 212. Vehicle service-oriented communication protocol; 213. Second CAN message processing module; 22. Atomic service module; 23. Combined service module; 24. MCU agent module; 25. Auxiliary system layer; 3. Vehicle middleware layer; 31. Protocol forwarding module; 32. Low latency communication module; 33. CAN bus; 4. Vehicle system M core; 41. AUTOSAR architecture module. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this utility model clearer, the technical solutions in the embodiments of this utility model are described clearly and completely. Obviously, the described embodiments are only some embodiments of this utility model, not all embodiments. Based on the embodiments of this utility model, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of this utility model.

[0020] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0021] This utility model discloses an on-board SOA testing device, according to the attached... Figure 1 As shown, it includes a host computer 1, an in-vehicle system A core 2, an in-vehicle middleware layer 3, and an in-vehicle system M core 4; the in-vehicle system A core 2 is equipped with a slave computer 21 and associated functional modules; the in-vehicle middleware layer 3 is used to realize data forwarding and communication adaptation; the in-vehicle system M core 4 is deployed with underlying architecture modules; The host computer 1 interacts with the vehicle system A core 2. The vehicle system A core 2, the vehicle middleware layer 3, and the vehicle system M core 4 are connected in sequence to form a data transmission path. The vehicle system A core 2 also achieves inter-module interaction through an inter-core communication framework.

[0022] The host computer 1 is equipped with a test master control program 11, a network communication module 12, and a first CAN message processing module 13. The network communication module 12 provides communication support for data interaction between the host computer 1 and the vehicle system A core 2.

[0023] According to the appendix Figure 1 As shown, the associated functional modules of the vehicle system A core 2 further include atomic service module 22, combined service module 23, MCU agent module 24 and auxiliary system layer 25. The atomic service module 22, combined service module 23 and MCU agent module 24 are all configured with an inter-core communication framework.

[0024] The lower-level machine 21 includes a test execution program 211, an in-vehicle service communication protocol 212, and a second CAN message processing module 213. The test execution program 211 is used to execute specific test procedures.

[0025] According to the appendix Figure 1 As shown, the vehicle middleware layer 3 further includes a protocol forwarding module 31, a low-latency communication module 32, and a CAN bus 33. The protocol forwarding module 31 realizes the conversion and forwarding of different protocol data.

[0026] The underlying architecture module of the M-core 4 of the vehicle system is the AUTOSAR architecture module 41, which provides underlying architecture support for the vehicle system.

[0027] Preferably, the first CAN message processing module 13 of the host computer 1 can encapsulate CAN data into a format suitable for communication of the vehicle system A core 2, and transmit it through the network communication module 12.

[0028] According to the appendix Figure 1 As shown, the MCU agent module 24 further communicates with the atomic service module 22, the combined service module 23, the vehicle service communication protocol 212, the auxiliary system layer 25, and the AUTOSAR architecture module 41 through the inter-core communication framework. The atomic service module 22 and the combined service module 23 can perform data interaction and functional collaboration with the test executor 211, the auxiliary system layer 25, the protocol forwarding module 31, and the low-latency communication module 32 based on the inter-core communication framework.

[0029] According to the appendix Figure 1 As shown, the host computer 1 can further send the test case script to the slave computer 21 through the network communication module 12, which will be executed by the test execution program 211. The vehicle service communication protocol 212 supports SOME / IP, DDS and MQTT transmission protocols and is used to conduct SOA service communication with the atomic service module 22, the composite service module 23, the protocol forwarding module 31 and the network communication module 12.

[0030] The low-latency communication module 32 enables low-latency data transmission between the CAN bus 33 and the protocol forwarding module 31.

[0031] The first CAN message processing module 13 of the host computer 1 simulates CAN data messages, replacing hardware devices such as CANOE and CDC, thus reducing hardware investment; at the same time, it supports the generation of test cases in no-code mode, which reduces the technical requirements for test engineers and saves labor costs.

[0032] The host computer 1 can send test case scripts to the slave computer 21 of the vehicle system A core 2 through the network communication module 12. The test execution program 211 will automatically execute the scripts, realizing full automation of scenario testing, stress testing, etc., greatly shortening the test cycle and completing a large number of test tasks in a short time.

[0033] It supports testing of multiple protocols such as SOME / IP and DDS. It implements complete in-loop testing logic through atomic service module 22 and composite service module 23. Combined with assertion comparison and automatic message parsing, it ensures comprehensive test coverage and accurate results. At the same time, test cases can be saved for a long time, which is convenient for continuous testing and service change tracking.

[0034] This invention achieves automated testing through the collaborative work of the host computer 1, the vehicle system A core 2, the vehicle middleware layer 3, and the vehicle system M core 4. The specific process is as follows: Test preparation: The user writes or selects test case scripts through the test master control program 11 of the host computer 1, and the first CAN message processing module 13 encapsulates the CAN data into the adaptation format.

[0035] Command transmission: The host computer 1 sends the script and commands to the slave computer 21 of the vehicle system A core 2 through the network communication module 12. After receiving the commands, the test execution program 211 of the slave computer 21 calls the atomic service module 22 or the combined service module 23 through the vehicle service communication protocol 212.

[0036] The A core 2 of the vehicle system achieves module collaboration through an inter-core communication framework. For example, the MCU agent module 24 forwards instructions to the atomic service module 22, and through the protocol forwarding module 31, low-latency communication module 32 and CAN bus 33 of the vehicle middleware layer 3, it realizes data interaction with the AUTOSAR architecture module 41 of the M core 4 of the vehicle system, and completes the underlying service call and status feedback.

[0037] Results Feedback and Analysis: The test results are returned to the lower computer 21 through the inter-core communication framework and uploaded to the upper computer 1 through the network communication module 12. The upper computer 1 parses the data, performs assertion comparison, displays the test status (such as success / failure) in real time, and generates a report to realize the closed loop of the entire test process.

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

[0039] The foregoing has shown and described the basic principles, main features, and advantages of this utility model. Those skilled in the art should understand that this utility model is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of this utility model. Various changes and modifications can be made to this utility model without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claims. The scope of protection of this utility model is defined by the appended claims and their equivalents.

Claims

1. A vehicle-mounted SOA testing device, characterized in that, It includes a host computer (1), an in-vehicle system A core (2), an in-vehicle middleware layer (3), and an in-vehicle system M core (4); the in-vehicle system A core (2) is equipped with a slave computer (21) and associated functional modules; the in-vehicle middleware layer (3) is used to realize data forwarding and communication adaptation; the in-vehicle system M core (4) is deployed with underlying architecture modules; The host computer (1) interacts with the vehicle system A core (2) to achieve data exchange. The vehicle system A core (2), the vehicle middleware layer (3), and the vehicle system M core (4) are connected in sequence to form a data transmission path. The vehicle system A core (2) realizes inter-module interaction through the inter-core communication framework.

2. The vehicle-mounted SOA testing equipment according to claim 1, characterized in that, The host computer (1) is equipped with a test master control program (11), a network communication module (12), and a first CAN message processing module (13). The network communication module (12) provides communication support for the data interaction between the host computer (1) and the vehicle system A core (2).

3. The vehicle-mounted SOA testing equipment according to claim 1, characterized in that, The associated functional modules of the vehicle system A core (2) include an atomic service module (22), a combined service module (23), an MCU agent module (24), and an auxiliary system layer (25). The atomic service module (22), the combined service module (23), and the MCU agent module (24) are all configured with an inter-core communication framework.

4. The vehicle-mounted SOA testing equipment according to claim 1, characterized in that, The lower-level machine (21) includes a test execution program (211), an in-vehicle service communication protocol (212), and a second CAN message processing module (213). The test execution program (211) is used to execute specific test procedures.

5. The vehicle-mounted SOA testing equipment according to claim 1, characterized in that, The vehicle middleware layer (3) is equipped with a protocol forwarding module (31), a low-latency communication module (32), and a CAN bus (33). The protocol forwarding module (31) realizes the conversion and forwarding of different protocol data.

6. The vehicle-mounted SOA testing equipment according to claim 1, characterized in that, The underlying architecture module of the vehicle system M core (4) is the AUTOSAR architecture module (41), which provides underlying architecture support for the vehicle system.

7. The vehicle-mounted SOA testing equipment according to claim 2, characterized in that, The first CAN message processing module (13) of the host computer (1) can encapsulate CAN data into a format suitable for communication of the vehicle system A core (2) and transmit it through the network communication module (12).

8. The vehicle-mounted SOA testing equipment according to claim 3, characterized in that, The MCU agent module (24) communicates with the atomic service module (22), the combined service module (23), the vehicle service communication protocol (212), the auxiliary system layer (25), and the AUTOSAR architecture module (41) through the inter-core communication framework. The atomic service module (22) and the combined service module (23) can interact with the test executor (211), the auxiliary system layer (25), the protocol forwarding module (31), and the low-latency communication module (32) based on the inter-core communication framework.

9. The vehicle-mounted SOA testing equipment according to claim 4, characterized in that, The host computer (1) can send the test case script to the slave computer (21) through the network communication module (12), which is then executed by the test execution program (211). The vehicle service communication protocol (212) supports SOME / IP, DDS, and MQTT transmission protocols and is used to conduct SOA service communication with the atomic service module (22), the combined service module (23), the protocol forwarding module (31), and the network communication module (12).

10. The vehicle-mounted SOA testing equipment according to claim 5, characterized in that, The low-latency communication module (32) enables low-latency data transmission between the CAN bus (33) and the protocol forwarding module (31).

Images