Vehicle data joint debugging test method, device, electronic equipment and storage medium

Abstract

The present application provides a vehicle data joint debugging test method, device, electronic device and storage medium. The method includes: creating a vehicle project protocol, processing the type field and field description in the vehicle project protocol based on a web page, and generating a protocol file; obtaining protocol data generated using the protocol file, comparing the fields in the protocol data with the fields corresponding to the preset protocol version, and determining the protocol version corresponding to the protocol data; determining the target system as the joint debugging test object, and selecting the target protocol version, generating test data using the target protocol version and test data generation rules; passing the test data to the target system through an HTTP communication interface or message middleware, so that the target system performs corresponding business processing based on the test data, so as to perform joint debugging testing of vehicle data. The present application improves protocol management efficiency, enhances the protocol version comparison function, improves joint debugging test efficiency and accuracy, and improves test flexibility.

Description

Technical Field

[0001] The present application relates to the field of new energy vehicle technology, and in particular to a vehicle data joint debugging and testing method, device, electronic equipment and storage medium. Background Art

[0002] With the development of the Internet of Vehicles, more and more data are beginning to interact between the vehicle side, the cloud side and various business systems. Since the technical programming languages ​​used on each side are very different, for example, the vehicle side usually uses C language, the cloud side usually uses Java, and the big data platform usually uses Python, the interaction between various systems is achieved through data transmission protocols.

[0003] However, during the protocol version iteration process, the latest protocol files and protocol change description documents need to be synchronized to the vehicle, cloud, and various business terminals. During the continuous system iteration process, the protocol is often added and modified, and the cloud must be continuously updated and synchronized to the vehicle, cloud, and various business terminals. If any end, such as the business system, does not synchronize the latest protocol, then the project will not be able to receive and process the latest protocol changes during operation, and it is difficult to determine which version of the protocol is used in each online environment.

[0004] In existing technical practices, current protocol version management methods have the following problems: system updates can lead to protocol changes, making it difficult to maintain and track multiple versions and their change logs. Manual synchronization of protocol files is currently inefficient and makes it difficult to compare version changes. Different system requirements inputs can lead to differences in protocol understanding and implementation, increasing maintenance and communication costs. The protocol versions currently used by online systems may be unclear, potentially leading to data loss or parsing errors. Different systems may have varying development speeds, leading to bottlenecks and difficulties in joint debugging. Summary of the Invention

[0005] In view of this, the embodiments of the present application provide a vehicle data joint debugging test method, device, electronic device and storage medium to solve the problems existing in the prior art, such as low efficiency of synchronization protocol files, increased maintenance and communication costs, easy to cause data loss or parsing errors, leading to blockage and difficulty in joint debugging.

[0006] A first aspect of an embodiment of the present application provides a vehicle data joint debugging and testing method, including: creating a vehicle project protocol, processing the type field and field description in the vehicle project protocol based on a web page, and generating a protocol file using the processed type field and field description; obtaining protocol data generated using the protocol file, comparing the fields in the protocol data with the fields corresponding to a preset protocol version, and determining the protocol version corresponding to the protocol data based on the comparison results; determining a target system as a joint debugging and testing object, and selecting a target protocol version for the joint debugging and testing, generating test data corresponding to the target protocol version using the target protocol version and predetermined test data generation rules; and transmitting the test data to the target system through an HTTP communication interface or a message middleware, so that the target system performs corresponding business processing based on the test data, so as to perform joint debugging and testing of vehicle data.

[0007] According to a second aspect of an embodiment of the present application, a vehicle data joint debugging and testing device is provided, comprising: a creation module configured to create a vehicle project protocol, process the type field and field description in the vehicle project protocol based on a web page, and generate a protocol file using the processed type field and field description; a comparison module configured to obtain protocol data generated using the protocol file, compare the fields in the protocol data with the fields corresponding to the preset protocol version, and determine the protocol version corresponding to the protocol data based on the comparison result; a generation module configured to determine a target system as a joint debugging and testing object, and select a target protocol version for the joint debugging and testing, and generate test data corresponding to the target protocol version using the target protocol version and predetermined test data generation rules; a test module configured to transmit the test data to the target system through an HTTP communication interface or a message middleware, so that the target system performs corresponding business processing based on the test data, so as to perform joint debugging and testing of vehicle data.

[0008] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the program.

[0009] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps of the above method are implemented.

[0010] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0011] By creating a vehicle project protocol, processing the type fields and field descriptions in the vehicle project protocol based on a web page, and generating a protocol file using the processed type fields and field descriptions; obtaining the protocol data generated using the protocol file, comparing the fields in the protocol data with the fields corresponding to the preset protocol version, and determining the protocol version corresponding to the protocol data based on the comparison results; determining the target system as the joint debugging test object, and selecting the target protocol version for the joint debugging test, generating test data corresponding to the target protocol version using the target protocol version and predetermined test data generation rules; passing the test data to the target system through the HTTP communication interface or message middleware, so that the target system performs corresponding business processing based on the test data, so as to perform joint debugging testing of vehicle data. This application improves protocol management efficiency, enhances the protocol version comparison function, improves joint debugging test efficiency and accuracy, and improves test flexibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 Schematic diagram of the process of the vehicle data joint debugging test method provided in the embodiment of the present application;

[0014] Figure 2 Schematic diagram of the structure of the vehicle data joint debugging and testing device provided in an embodiment of the present application;

[0015] Figure 3 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0016] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0017] As described in the background, with the development of the Internet of Vehicles (IoV), more and more data is interacting between the vehicle, the cloud, and various business systems. Due to the significant differences in the programming languages ​​used by each end—for example, C is commonly used on the vehicle, Java is commonly used on the cloud, and Python is often used on big data platforms—the most widely used data transmission protocol during this interaction is protocol buffers. Protocol buffers are a language-independent, platform-independent, and scalable method for serializing structured data. They are used for data communication protocols and data storage, offering compact size and fast encoding and decoding speeds.

[0018] Generally speaking, cloud-based TSP developers are responsible for writing proto protocol files. During the iteration process, they synchronize the latest proto protocol files and protocol change description documents to the vehicle, cloud, and various business terminals. During the continuous iteration of the system, protocols are often added and modified, and the cloud-based TSP must continuously update and synchronize them to the vehicle, cloud, and various business terminals. If any end, such as the business system, does not synchronize the latest protocol, it will not be able to receive and process the latest protocol changes during the project operation, and it is difficult to determine which version of the protocol is used in each online environment.

[0019] Because the development progress and protocol understanding of in-vehicle systems, cloud systems, and business systems may differ, there are some significant technical issues in protocol version management and synchronization, including:

[0020] (1) Protocol version maintenance and tracking issues: The increasing number of protocol versions makes it difficult to maintain and record historical changes. Manual synchronization, which involves synchronizing protocol files to each end point, is highly repetitive and inefficient. Furthermore, it is inconvenient to compare changes between any two versions.

[0021] (2) Issues with protocol content alignment and understanding: The protocol content on each end is difficult to align, and the specific protocol field descriptions are inconsistently understood on each end. Demand input sometimes comes from Tbox and sometimes from apps or other demand parties. Manually synchronizing the protocol to each end after it is established is costly, both in terms of maintenance and communication, and real-time alignment between the ends is not always possible.

[0022] (3) Tracking the online system protocol version: Currently, it is unclear which protocol version is used by each system interacting online. For example, Tbox uses the V1.0.1 protocol, while the cloud uses the new version V1.0.2. The difference between the two is that V1.0.2 has some additional content fields. When Tbox reports data to TSP, these new contents will be missing. Conversely, the same situation occurs when data is sent from V1.0.2 to version V1.0,1, and the other party cannot parse it properly. When this data is indeed problematic, the protocol version should be considered first, but there is currently no tool to locate the data version.

[0023] (4) Inconsistent development progress: The development progress of each end is inconsistent, which often leads to mutual obstruction and difficulty in unified joint debugging. For example, when some new functions are added, involving the APP end, TSP end, and TBOX end, the development progress of each end is usually inconsistent. This will result in one end, such as TBOX, being developed and wanting to be unified and debugged, while the other ends are still under development.

[0024] In view of the problems existing in the above-mentioned prior art, an embodiment of the present application provides a vehicle data joint debugging and testing method. The present application processes and generates vehicle project protocols in a web-based manner, and the creation, viewing, adding, editing or comparison operations of the protocol are more convenient and intuitive, thereby significantly improving the efficiency of protocol management. At the same time, by setting a new protocol version identifier for the protocol file, each protocol version can be clearly tracked and managed. The present application can easily compare the differences between adjacent protocol versions or non-adjacent protocol versions, improve the convenience of protocol version comparison and management, help to better understand and track protocol changes, and enhance the protocol version comparison function. The present application generates corresponding test data through predetermined test data generation rules and target protocol versions, which can be passed to the target system through the HTTP communication interface or message middleware for joint debugging and testing; and the technical solution of the present application makes the test more flexible and can perform joint debugging and testing more accurately, thereby improving the efficiency and accuracy of joint debugging and testing.

[0025] The contents of the technical solution of this application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] Figure 1 It is a flow chart of the vehicle data joint debugging and testing method provided in an embodiment of the present application. Figure 1 The vehicle data joint debugging test method can be executed by the server. Figure 1 As shown, the vehicle data joint debugging test method may specifically include:

[0027] S101, creating a vehicle project agreement, processing the type field and field description in the vehicle project agreement based on a web page, and generating a protocol file using the processed type field and field description;

[0028] S102, obtaining protocol data generated using the protocol file, comparing fields in the protocol data with fields corresponding to a preset protocol version, and determining the protocol version corresponding to the protocol data based on the comparison result;

[0029] S103, determining a target system as a joint debugging test object, selecting a target protocol version for the joint debugging test, and generating test data corresponding to the target protocol version using the target protocol version and a predetermined test data generation rule;

[0030] S104: The test data is delivered to the target system via the HTTP communication interface or message middleware, so that the target system performs corresponding business processing according to the test data, so as to perform joint debugging test of vehicle data.

[0031] Protocol Buffers (often abbreviated as protobuf) is a data format that can be used for data serialization and deserialization. Serialization converts a data structure or object into a binary or text format that can be stored or transmitted, while deserialization converts the data back into the original object or data structure.

[0032] The application of Protocol Buffers in new energy vehicle technology is primarily concentrated in areas such as connected vehicles and autonomous driving. These scenarios require data communication and interaction between different devices, platforms, and programming languages, such as between vehicle control units (ECUs), cloud services, and user applications.

[0033] Specifically, Protocol Buffers has the following main advantages:

[0034] Platform- and language-independent: Protocol Buffers defines a neutral interface description language (IDL) for describing data structures. These interface descriptions can be compiled into code in multiple languages, including C++, Java, and Python, using the protobuf compiler. This makes protobuf ideal for data communication between different systems and languages.

[0035] High efficiency and small data size: Protocol Buffers serialized data is very compact, usually much smaller than data in formats such as XML and JSON. At the same time, encoding and decoding efficiency is also very high.

[0036] Strong compatibility: Protocol Buffers is designed to be both forward and backward compatible, which means you can gradually update data structures and interfaces without interrupting services.

[0037] Explicit data model: Protocol Buffers uses an explicit data model and type system to better ensure data integrity and accuracy.

[0038] Therefore, Protocol Buffers plays a key role in data interaction in the field of new energy vehicles.

[0039] In some embodiments, a vehicle project agreement is created, and the type fields and field descriptions in the vehicle project agreement are processed based on a web page, including: using a web page to create a vehicle project agreement based on the vehicle model, and viewing, adding, editing or comparing the agreement fields and field descriptions in the vehicle project agreement on the web page.

[0040] Specifically, the protocol management system of the embodiment of the present application provides the ability to create, edit, and compare historical versions of vehicle project agreements (i.e., vehicle project agreements) online. The embodiment of the present application can create and manage vehicle project agreements based on a web page. First, a vehicle project agreement is created based on the vehicle model using a web page. For example, assuming a project with a vehicle model of "X1", a new protocol project named "X1 Project Agreement" can be created on the web page.

[0041] Furthermore, the web page allows you to view, add, edit, and compare the protocol fields and field descriptions within the "X1 Project Protocol." For example, if a simple protocol includes doors and windows, users can enter the relevant protocol fields and descriptions on the web page. This is done by dragging and dropping text boxes, making it very intuitive and convenient.

[0042] In a specific example, a user might add the following protocol fields and descriptions:

[0043] {

[0044] message MsgTop{

[0045] MsgDoor door; / / car door

[0046] MsgWindow window; / / car window

[0047] }

[0048] message MsgDoor{

[0049] string left_front_door; / / left front door

[0050] string right_front_door; / / right front door

[0051] string left_behind_door; / / left back door

[0052] string right_behind_door; / / right back door

[0053] }

[0054] message MsgWindow{

[0055] string left_front_window; / / left front window

[0056] string right_front_window; / / right front window

[0057] string left_behind_window; / / left rear window

[0058] string right_behind_window; / / right rear window

[0059] }

[0060] }

[0061] After the user completes editing and selects Save, the system backend will automatically save the edited protocol information, including the editing time. Alternatively, the user can click Download, and the system backend will generate a protocol file named "X1_V1.0.1.proto" based on the edited protocol information and download it. This protocol file is a serialized protobuf file that contains the edited protocol fields and descriptions and can be used for data communication or data storage.

[0062] As can be seen from the above examples, this application enables online creation, editing, viewing, and downloading of vehicle project agreements, providing a very convenient tool that can improve the management efficiency of vehicle project agreements and reduce management costs. Furthermore, because the method of this application supports online comparison of protocol versions, it can also effectively track and manage protocol versions, reducing the problems that may arise from inconsistent protocol versions.

[0063] In some embodiments, after generating a protocol file using the processed type field and field description, the method further includes: setting a new protocol version identifier for the protocol file, and establishing a mapping relationship between each field in the protocol file and the protocol version identifier; when comparing the differences between adjacent protocol versions, determining the fields that have changed between adjacent protocol versions based on the protocol version identifier; when comparing the differences between non-adjacent protocol versions, determining the fields that have changed between the adjacent protocol versions of two non-adjacent protocol versions in turn, and taking the sum of the fields that have changed between all adjacent protocol versions as the difference between the two non-adjacent protocol versions.

[0064] Specifically, the protocol management system of this embodiment also implements web-based vehicle project protocol version management and comparison. After generating a protocol file using the processed type field and field description, the system sets a new protocol version identifier for the protocol file, such as "V1.0.1." This version identifier is associated with each field in the protocol file, forming a mapping relationship between the field and the protocol version identifier. This mapping relationship facilitates tracking the version history and changes of each field.

[0065] During the version comparison process, users can select two versions to compare. The system will determine the fields that have changed between adjacent versions based on the protocol version identifier. For example, if a user selects "V1.0.1" and "V1.0.2" to compare, the system will display all the fields that have changed between the two versions.

[0066] If you need to compare two non-adjacent versions, such as V1.0.1 and V1.0.4, the system will compare the differences between adjacent intermediate versions, including the differences between V1.0.1 and V1.0.2, V1.0.2 and V1.0.3, and V1.0.3 and V1.0.4. The system will aggregate all these differences and report them as the difference between V1.0.1 and V1.0.4, allowing you to understand the full range of changes between the two non-adjacent versions.

[0067] In an example, the specific implementation logic of the protocol version difference comparison method is as follows:

[0068] First, the system stores each protocol file in the database. Each field in the protocol file corresponds to its own protocol version identifier, such as "V1.0.1." When the version is subsequently changed, the system determines the version identifier based on the newly added field.

[0069] Secondly, when a user requests to compare two versions, the system will query all the fields of the two versions from the database, as well as the version identifier corresponding to each field.

[0070] The system then compares the fields and version identifiers of the two versions to identify the fields that differ. If the two versions are adjacent, the system directly displays the difference fields. If the versions are non-adjacent, the system compares the differences between each adjacent intermediate version in turn and then summarizes all the difference fields.

[0071] Finally, the system displays the comparison results on a web page for users to view.

[0072] In another embodiment, the system can also provide a detailed version description for each version, including information such as the reason for the version change, the functional modules involved, and the impact of the change. When users compare versions, in addition to seeing the difference fields between the versions, they can also see these detailed version descriptions, allowing them to more fully understand the content and significance of the version change.

[0073] In another embodiment, the system can also provide a version rollback function. If the user finds a problem with the new version, they can directly roll back to the old version without manually modifying the protocol file. This function can greatly improve the efficiency of version management and reduce the business impact caused by version issues.

[0074] According to the technical solution provided in the embodiment of the present application, the method of the embodiment of the present application can conveniently manage and compare protocol versions, help users quickly understand the differences between different versions, and reduce problems caused by version inconsistencies.

[0075] In some embodiments, the protocol management system of the embodiment of the present application also provides a protocol version verification function (i.e., version locating of data). In actual applications, by obtaining protocol data generated using a protocol file, the fields in the protocol data are compared with the fields corresponding to the preset protocol version, and the protocol version corresponding to the protocol data is determined based on the comparison results. The specific implementation process and principle of the protocol version verification are described in detail below in conjunction with specific embodiments, which may include the following:

[0076] The protocol management system of the embodiment of the present application can not only create, edit and compare protocol versions, but also has the function of protocol version verification, that is, it can determine its corresponding protocol version according to the content of the data packet. When the system receives a data packet (i.e., protocol data), it will obtain the various fields in the data packet. The system will then compare these fields with the fields in the protocol files of different versions stored in the database. By comparing, the system can determine the proto protocol version corresponding to the data packet. In order to optimize the comparison efficiency, the comparison process usually starts from the latest protocol version and is compared forward one by one until the protocol version that fully matches the data packet field is found.

[0077] In one example, if a packet contains a field called "Skylight" that was added in version V1.0.2, the system will determine that the protocol version corresponding to the packet is at least V1.0.2. If the packet does not contain a field that was added in version V1.0.3 or later, the system will determine that the protocol version corresponding to the packet is V1.0.2.

[0078] The protocol version verification function provided by the embodiments of the present application is very useful for troubleshooting online problems. For example, if data loss occurs during data transmission, version verification can quickly locate the protocol version corresponding to the problematic data packet, thereby more accurately locating and resolving the problem. In addition, this protocol version verification function can also help maintenance teams better manage and monitor the various protocol versions used in the system, and promptly detect and address version inconsistencies. Furthermore, the embodiments of the present application further enhance the intelligence and practicality of the protocol management system, enabling it to better meet user needs and improve work efficiency.

[0079] In some embodiments, test data corresponding to the target protocol version is generated using the target protocol version and predetermined test data generation rules, including: obtaining the default fields and field types in the test data generation rules according to the test data generation rules configured for the target protocol version, randomly filling the values ​​of the default fields according to the field types, or specifying numerical values ​​for the default fields in the web page to generate test data corresponding to the target protocol version.

[0080] Specifically, the protocol management system of the present embodiment can also generate simulated test data, thereby helping users to more effectively conduct system joint debugging and testing. In actual applications, the system provides a simulated data generation module that can generate corresponding test data for a specified protocol version based on preset test data generation rules. Test data generation rules can include information such as default fields, field types, and data generation methods.

[0081] In one example, for fields of fixed value types, such as "car model", "car series", "vehicle attributes", etc., the system can preset some hard-coded values ​​(such as "M7", etc.). For integer value fields, such as window opening, speed, and endurance, the system can preset a value range and randomly generate values ​​within this range, for example: window opening constraint 0 to 100, speed constraint 0 to 120, and endurance constraint 0 to 2000. For enumeration value fields, such as light switches, door switches, gears, etc., the system can randomly select values ​​from the preset enumeration values. For time type fields, the system can generate real-time time, or set the time according to business needs.

[0082] In addition to randomly generating data, the system also provides a web-based data entry function for specific protocols. Users can specify values ​​for default fields on the web page to generate specific test data. This feature is particularly useful for joint debugging simulations where fixed data, such as device numbers and vehicle chassis numbers, is required.

[0083] This embodiment of the present application improves the practicality of the protocol management system, can better support the system's joint debugging and testing, and improve testing efficiency and accuracy.

[0084] In some embodiments, the test data is passed to the target system through the HTTP communication interface, and the vehicle data joint debugging test is performed, including: obtaining the dynamically input URL address of the target system, calling the URL address of the target system, and sending an HTTP request to the URL address of the target system so as to send the test data corresponding to the target protocol version to the target system, so that the target system can perform joint debugging test based on the test data.

[0085] Specifically, to address the issue of inconsistent development progress across different systems and the resulting inability to integrate and debug, the protocol management system in this embodiment further provides a simulated debugging function. In practical applications, the system provides data receiving and sending modules. The data receiving module can receive test data via HTTP. After receiving the data, it will output all the data information, including the version to which the data belongs, for the user to view. The data sending module can generate corresponding test data based on the protocol version selected by the user and send it to the user's own system for interaction.

[0086] This system is compatible with various data exchange methods, including HTTP and messaging middleware (such as Kafka and EMQ). For systems using HTTP, users can dynamically enter the target system's URL, select the protocol version, and set the rules for generating simulated data. The system backend then sends HTTP requests to the target system based on the provided URL and generated simulated data.

[0087] In one example, for a target system that uses HTTP requests as its data input method, the user can select the latest protocol version to generate test data. Based on the target system's URL, protocol version, and simulation data generation rules, the system automatically generates the corresponding version of test data and sends it to the target system. After receiving the test data from the protocol backend system, the target system can then perform business matching based on this test data.

[0088] The test method provided by this embodiment can select any historical version of the protocol, which is very flexible and does not rely on any other system, and can be tested repeatedly independently. In addition, the user can also configure the number of transmissions per unit time to perform a simple stress test. In addition, when a new protocol file is generated, the system can synchronize the new protocol file to each system. The test data generated according to the latest protocol version will be sent to the corresponding system according to the data input method of each system. In this way, end-to-end joint debugging of different protocols and different modes can be achieved. Therefore, the above-mentioned embodiment of the present application provides a flexible testing method that can effectively support joint debugging tests of different systems.

[0089] In some embodiments, the test data is passed to the target system through the message middleware, and a joint debugging test of the vehicle data is performed, including: obtaining the message middleware server address input by the user and the subject corresponding to the message, connecting to the message middleware server according to the message middleware server address, and passing the test data to the message middleware server, so that the target system uses the test data in the message middleware server for joint debugging testing.

[0090] Specifically, the protocol management system of the embodiment of the present application can also transmit test data to the target system through the message middleware to perform joint debugging tests on vehicle data. When using the message middleware for joint debugging tests, the user first selects the message middleware type on the web side. Currently, this system supports a variety of common message middleware, such as Kafka, EMQ, etc. Then, the user needs to enter the address of the message middleware server and the topic corresponding to the message. This information is crucial for the system background to connect to the message middleware server and send messages to the corresponding topics.

[0091] After obtaining this information, the system backend will begin processing. First, based on the message middleware server address provided by the user, the system backend will attempt to connect to the server. Once the connection is successfully established, the system backend will begin generating test data. This test data will be generated according to the protocol version specified by the user and the simulation data generation rules.

[0092] Next, the system backend will encapsulate this test data into a message and publish it to the user-specified topic. During this process, the system backend will use the appropriate publishing method based on the type of message middleware. For example, if the message middleware is Kafka, the system backend will use Kafka's producer API for publishing; if the message middleware is EMQ, the system backend will use the MQTT protocol for publishing.

[0093] Alternatively, the target system can receive the test data from the message middleware server by subscribing to the corresponding topic. The target system can then perform joint debugging tests based on the received test data. In this way, the protocol management system of the embodiment of the present application can support joint debugging tests through the message middleware, increasing the flexibility of the test and better meeting the joint debugging requirements of different systems.

[0094] Optionally, the protocol file in the embodiment of the present application is a proto protocol file, the protocol version is a proto protocol version, and the protocol data and test data are both proto protocol data.

[0095] According to the technical solution provided in the embodiment of the present application, the present application provides a protocol management system, which adds and edits protocols in an intuitive way, annotates each field, including when, who inputs it, what its function is, etc., and records changes. It can then dynamically generate proto protocol files based on the above editing and provide external downloads, provide protocol version verification, provide protocol data simulation, provide protocol historical version management, and provide protocol joint debugging support, thereby improving R&D quality and R&D efficiency. The present application systematically manages the creation, editing, viewing, version comparison and testing of protocols, and uses web pages to process vehicle project protocols, making protocol management more intuitive and convenient; at the same time, it generates test data in combination with predetermined test data generation rules and target protocol versions, and selects appropriate test methods according to system requirements, thereby improving the efficiency and accuracy of joint debugging tests.

[0096] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0097] Figure 2 This is a schematic diagram of the structure of the vehicle data joint debugging test device provided in the embodiment of the present application. Figure 2 As shown, the vehicle data joint debugging test device includes:

[0098] A creation module 201 is configured to create a vehicle project agreement, process the type field and field description in the vehicle project agreement based on a web page, and generate a protocol file using the processed type field and field description;

[0099] The comparison module 202 is configured to obtain protocol data generated using the protocol file, compare fields in the protocol data with fields corresponding to a preset protocol version, and determine the protocol version corresponding to the protocol data based on the comparison result;

[0100] The generation module 203 is configured to determine a target system as a joint debugging test object, select a target protocol version for the joint debugging test, and generate test data corresponding to the target protocol version using the target protocol version and a predetermined test data generation rule;

[0101] The test module 204 is configured to transmit the test data to the target system through the HTTP communication interface or the message middleware, so that the target system performs corresponding business processing according to the test data, so as to perform the joint debugging test of the vehicle data.

[0102] In some embodiments, Figure 2 The creation module 201 creates a vehicle project agreement based on the vehicle model using a web page, and views, adds, edits, or compares the agreement fields and field descriptions in the vehicle project agreement on the web page.

[0103] In some embodiments, after generating the protocol file using the processed type field and field description, Figure 2 The comparison module 202 sets a new protocol version identifier for the protocol file and establishes a mapping relationship between each field in the protocol file and the protocol version identifier; when comparing the differences between adjacent protocol versions, the fields that have changed between the adjacent protocol versions are determined based on the protocol version identifier; when comparing the differences between non-adjacent protocol versions, the fields that have changed between the adjacent protocol versions of two non-adjacent protocol versions are determined in sequence, and the sum of the fields that have changed between all adjacent protocol versions is used as the difference between the two non-adjacent protocol versions.

[0104] In some embodiments, Figure 2 The generation module 203 obtains the default fields and field types in the test data generation rules according to the test data generation rules configured for the target protocol version, randomly fills the values ​​of the default fields according to the field types, or specifies numerical values ​​for the default fields in the web page to generate test data corresponding to the target protocol version.

[0105] In some embodiments, Figure 2 The test module 204 obtains the dynamically input URL address of the target system, calls the URL address of the target system, and sends an HTTP request to the URL address of the target system to send the test data corresponding to the target protocol version to the target system, so that the target system can perform joint debugging tests based on the test data.

[0106] In some embodiments, Figure 2The test module 204 obtains the message middleware server address and the subject corresponding to the message input by the user, connects to the message middleware server according to the message middleware server address, and passes the test data to the message middleware server, so that the target system uses the test data in the message middleware server for joint debugging testing.

[0107] In some embodiments, the protocol file is a proto protocol file, the protocol version is a proto protocol version, and the protocol data and test data are both proto protocol data.

[0108] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0109] Figure 3 Schematic diagram of the structure of the electronic device 3 provided in the embodiment of the present application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, the steps of the above-mentioned method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0110] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to implement the present application. One or more modules / units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of computer program 303 in electronic device 3.

[0111] The electronic device 3 may be a desktop computer, a notebook, a PDA, a cloud server or other electronic device. The electronic device 3 may include but is not limited to a processor 301 and a memory 302. Those skilled in the art will understand that Figure 3 It is only an example of electronic device 3 and does not constitute a limitation of electronic device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0112] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0113] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard drive or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the electronic device 3. Furthermore, the memory 302 can include both an internal storage unit of the electronic device 3 and an external storage device. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or is about to be output.

[0114] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0115] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0116] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0117] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer equipment and methods can be implemented in other ways. For example, the apparatus / computer equipment embodiments described above are merely schematic. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of the apparatus or unit, which may be electrical, mechanical or other forms.

[0118] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0119] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0120] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0121] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A vehicle data joint debugging test method, characterized in that: include: Creating a vehicle project agreement, processing a type field and a field description in the vehicle project agreement based on a web page, and generating a protocol file using the processed type field and field description; Acquire protocol data generated using the protocol file, compare fields in the protocol data with fields corresponding to a preset protocol version, and determine the protocol version corresponding to the protocol data based on the comparison result; Determine a target system as a joint debugging test object, select a target protocol version for the joint debugging test, and generate test data corresponding to the target protocol version using the target protocol version and a predetermined test data generation rule; The test data is transmitted to the target system through an HTTP communication interface or a message middleware, so that the target system performs corresponding business processing according to the test data, so as to perform a joint debugging test of the vehicle data; After generating the protocol file using the processed type field and field description, the method further includes: Setting a new protocol version identifier for the protocol file, and establishing a mapping relationship between each field in the protocol file and the protocol version identifier; When comparing differences between adjacent protocol versions, determining, based on the protocol version identifier, fields that have changed between adjacent protocol versions; When comparing differences between non-adjacent protocol versions, the fields that have changed between adjacent protocol versions of the two non-adjacent protocol versions are determined in sequence, and the sum of the fields that have changed between all adjacent protocol versions is taken as the difference between the two non-adjacent protocol versions.

2. The method according to claim 1, characterized in that The creating of the vehicle project agreement, processing the type field and field description in the vehicle project agreement based on the web page, includes: The vehicle project agreement is created according to the vehicle model using the web page, and the agreement fields and field descriptions in the vehicle project agreement are viewed, added, edited or compared on the web page.

3. The method according to claim 1, characterized in that The generating of test data corresponding to the target protocol version by using the target protocol version and a predetermined test data generation rule includes: According to the test data generation rule configured for the target protocol version, the default field and field type in the test data generation rule are obtained, and the value of the default field is randomly filled according to the field type, or a numerical value is specified for the default field in the web page to generate test data corresponding to the target protocol version.

4. The method according to claim 3, characterized in that The test data is transmitted to the target system via the HTTP communication interface, and a joint debugging test of the vehicle data is performed, including: Obtain the dynamically input URL address of the target system, call the URL address of the target system, and send an HTTP request to the URL address of the target system to send the test data corresponding to the target protocol version to the target system, so that the target system can perform joint debugging tests based on the test data.

5. The method according to claim 3, characterized in that The test data is delivered to the target system through the message middleware, and the vehicle data joint debugging test is performed, including: Obtain the message middleware server address and the subject corresponding to the message input by the user, connect to the message middleware server according to the message middleware server address, and pass the test data to the message middleware server, so that the target system uses the test data in the message middleware server for joint debugging testing.

6. The method according to any one of claims 1 to 5, characterized in that The protocol file is a proto protocol file, the protocol version is a proto protocol version, and the protocol data and the test data are both proto protocol data.

7. A vehicle data joint debugging and testing device, characterized in that: include: a creation module configured to create a vehicle project agreement, process a type field and a field description in the vehicle project agreement based on a web page, and generate a protocol file using the processed type field and field description; a comparison module configured to obtain protocol data generated using the protocol file, compare fields in the protocol data with fields corresponding to a preset protocol version, and determine the protocol version corresponding to the protocol data based on the comparison result; a generation module configured to determine a target system as a joint debugging test object, select a target protocol version for the joint debugging test, and generate test data corresponding to the target protocol version using the target protocol version and a predetermined test data generation rule; A testing module is configured to transmit the test data to the target system via an HTTP communication interface or a message middleware, so that the target system performs corresponding business processing according to the test data, so as to perform a joint debugging test of the vehicle data; The comparison module is configured to, after generating a protocol file using the processed type field and field description, set a new protocol version identifier for the protocol file and establish a mapping relationship between each field in the protocol file and the protocol version identifier; when comparing differences between adjacent protocol versions, determine the fields that have changed between adjacent protocol versions based on the protocol version identifier; When comparing differences between non-adjacent protocol versions, the fields that have changed between adjacent protocol versions of the two non-adjacent protocol versions are determined in sequence, and the sum of the fields that have changed between all adjacent protocol versions is taken as the difference between the two non-adjacent protocol versions.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images