Remote debugging methods, systems, and related electronic equipment for vehicle model debugging

Abstract

This application proposes a remote debugging method, system, and related electronic equipment for vehicle model debugging, relating to the field of automotive diagnostic technology. The method includes: sending target vehicle data to a remote control terminal; receiving page data sent by the remote control terminal; displaying a real diagnostic page corresponding to the page data on a local user interface and collecting user interaction operations on the real diagnostic page; and transmitting diagnostic status information generated based on the interaction operations back to the remote control terminal, so that the remote control terminal can continue executing the vehicle diagnostic program according to the diagnostic status information. The embodiments of this application can facilitate vehicle engineers to quickly debug and repair the vehicle diagnostic process.

Description

Technical Field

[0001] This application relates to the field of automotive diagnostic technology, and in particular to a remote debugging method, system, and related electronic equipment for vehicle model debugging. Background Technology

[0002] In the automotive diagnostics industry, vehicle diagnostic programs are typically developed by vehicle engineers in Windows or macOS environments and then deployed to Android diagnostic devices for practical verification. However, due to differences in vehicle models, Android's interface rendering mechanism, thread scheduling strategy, cross-process communication timing, and OBD lower-level machine return characteristics compared to the PC, many program defects only become apparent in the real Android runtime environment. Examples include abnormal page switching, erratic interface states, failure to advance the process after a button click, and the page not refreshing after an OBD return. Existing debugging methods mainly rely on PC-based simulation, migrating the entire vehicle logic to Android for debugging, or post-event analysis using screen recording, log recording, and manual reproduction. These methods either fail to accurately reproduce the Android runtime environment, disrupt existing development practices and incur high deployment costs, or only provide the result of the problem rather than the real-time runtime status, leading to inefficient bug localization. Summary of the Invention

[0003] This application provides a remote debugging method, system, and related electronic equipment for vehicle model debugging, in order to solve the problems existing in related technologies. The technical solution is as follows: In a first aspect, embodiments of this application provide a remote debugging method for vehicle model debugging, applied to a diagnostic equipment terminal, the method comprising: Send the target vehicle's data information to the remote control terminal; Receive page data sent by the remote control terminal; Display the actual diagnostic page corresponding to the page data on the local user interface, and collect user interaction operations on the actual diagnostic page; The diagnostic status information generated based on the interactive operation is sent back to the remote control terminal so that the remote control terminal can continue to execute the vehicle diagnostic program according to the diagnostic status information.

[0004] In one implementation, before sending the target vehicle's data information to the remote control terminal, the process further includes: Display mode selection options; the options should include at least remote debugging mode and local diagnostic mode; Obtain the mode selection command input by the user; When the mode selection command indicates remote debugging mode, a remote diagnostic request is triggered; The local diagnostic process is shut down, and the local TCP service is started, sending a communication connection request to establish a communication connection with the remote control terminal.

[0005] In one implementation, the communication connection includes at least two independent connection channels: The page data channel is used to receive page data, start data, and exit data sent from the remote control terminal, as well as to send page interaction results back to the remote control terminal. The OBD data channel is used to report data information, diagnostic status information, and interactive feedback information collected from the target vehicle's OBD system to the remote control terminal.

[0006] In one implementation, receiving page data sent by the remote control terminal includes: Receive unified data frames sent by the remote control terminal. The unified data frame includes at least a length field, a type field, and a data area. Parse page data from a unified data frame; The length field occupies 4 bytes, uses little-endian order, and its value is the total number of bytes of the length field itself, the type field, and the data area. The type field occupies 1 byte and is used to indicate the service type of the current data frame. Service types include handshake, vehicle model loading, startup, exit, page data, OBD command, data acquisition, vehicle information, and secure access.

[0007] In one implementation, it further includes: If the diagnostic status information indicates that the diagnostic is complete, obtain the debug log; Send the debug logs to the remote control terminal.

[0008] Secondly, embodiments of this application provide a remote debugging method for vehicle model debugging, applied to a remote control terminal, including: Receive data information from the target vehicle; Based on the data, determine the diagnostic execution strategy; According to the diagnostic execution strategy, send the page data of the target page to the diagnostic device terminal; Receive diagnostic status information; Determine the next execution step based on the diagnostic status information; Send the page data corresponding to the next execution step to the diagnostic device terminal.

[0009] Thirdly, embodiments of this application provide a remote joint debugging system for vehicle model debugging, including: The diagnostic equipment terminal communicates with the OBD interface of the target vehicle. The remote control terminal is remotely connected to the diagnostic equipment terminal. The diagnostic equipment terminal is loaded with local diagnostic programs and remote diagnostic programs, and the local diagnostic programs and remote diagnostic programs use the same data frame.

[0010] In one embodiment, the diagnostic device terminal includes: The data information sending module is used to send the target vehicle's data information to the remote control terminal; The content receiving module is used to receive page data sent by the remote control terminal. The page display module is used to display the actual diagnostic page corresponding to the page data on the local user interface and to collect user interaction operations on the actual diagnostic page. The feedback module is used to send back the diagnostic status information generated based on the interactive operation to the remote control terminal, so that the remote control terminal can continue to execute the vehicle diagnostic program according to the diagnostic status information.

[0011] In one implementation, the remote control terminal includes: The data receiving module is used to receive data information from the target vehicle; The fault handling module is used to determine the diagnostic execution strategy based on data information; The content sending module is used to send page data of the target page to the diagnostic device terminal according to the diagnostic execution strategy; The data receiving module is also used to receive diagnostic status information; The fault handling module is also used to determine the next execution step based on the diagnostic status information; The content sending module is also used to send the page data corresponding to the next execution step to the diagnostic device terminal.

[0012] Fourthly, embodiments of this application provide an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to execute the aforementioned remote debugging method for vehicle model debugging.

[0013] Fifthly, embodiments of this application provide a computer-readable storage medium that stores computer instructions, wherein when the computer instructions are executed on a computer, the methods in any of the above-described embodiments are performed.

[0014] The remote debugging method for vehicle models provided in this application executes diagnostic decisions through a remote control terminal, driving the Android device to display real pages and collect real interactions. This allows bugs that were originally only exposed during Android runtime, such as abnormal page switching, disordered interface states, and failure to advance the process after clicking a button, to be quickly reproduced and fixed. After modifying the vehicle logic on the PC, vehicle engineers can update the local diagnostic program loaded on the diagnostic device terminal, enabling the rapid repair and resolution of problems that would have occurred during the local diagnostic program's runtime, thus improving the user experience.

[0015] The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of this application will become readily apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0016] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0017] Figure 1 A schematic flowchart illustrating a remote joint debugging method for vehicle model debugging according to an embodiment of this application is shown.

[0018] Figure 2 This diagram illustrates a timing flow chart of page data debugging during remote integration testing according to an embodiment of this application.

[0019] Figure 3 This diagram illustrates a schematic flowchart of initiating remote commissioning according to an embodiment of the present application.

[0020] Figure 4 A schematic flowchart illustrating a remote joint debugging method for vehicle model debugging according to another embodiment of this application is shown.

[0021] Figure 5 This diagram illustrates a schematic flowchart of OBD lower-level machine data debugging according to an embodiment of the present application.

[0022] Figure 6 A schematic structural block diagram of a remote joint debugging system for vehicle model debugging according to an embodiment of this application is shown.

[0023] Figure 7 This is a block diagram of an electronic device used to implement the remote joint debugging method for vehicle model debugging in the embodiments of this application. Detailed Implementation

[0024] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0025] This application provides a remote debugging method for vehicle model debugging. The system architecture environment in which it is applied includes a diagnostic equipment terminal and a remote control terminal, and a communication connection can be selectively established between the diagnostic equipment terminal and the remote control terminal.

[0026] The remote control terminal can be a PC (Personal Computer) with a Windows or MacOS operating environment. The remote control terminal runs a vehicle diagnostic program containing complete vehicle diagnostic logic.

[0027] The diagnostic equipment terminal serves as the user's operating end. It communicates with the OBD (On-Board Diagnostics) interface of the target vehicle. Communication can be wired (e.g., via a diagnostic cable) or wireless (e.g., via Bluetooth or Wi-Fi). The diagnostic equipment terminal acquires data from the target vehicle through the OBD interface and transmits this data to the remote control terminal via a communication connection, enabling the remote control terminal to perform diagnostics on the target vehicle based on its diagnostic logic.

[0028] The remote control terminal determines the diagnostic execution strategy based on the received OBD data information and sends the page data corresponding to the diagnostic steps to the diagnostic device terminal for display, so as to prompt the user to perform the diagnostic operation according to the diagnostic steps.

[0029] In addition, the diagnostic equipment terminal also has a vehicle diagnostic program loaded locally. When the diagnostic equipment terminal and the remote control terminal have not established a communication connection, the diagnostic equipment terminal can run the local vehicle diagnostic program independently and complete the vehicle diagnostic function locally.

[0030] This application first provides a remote debugging method for vehicle model debugging, applied to a diagnostic equipment terminal. The diagnostic equipment terminal can be an Android diagnostic device, a tablet computer, or a dedicated vehicle diagnostic tool. The diagnostic equipment terminal includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method steps of this application embodiment. The diagnostic equipment terminal also includes a user interface for displaying diagnostic pages and collecting user interaction operations; the diagnostic equipment terminal also includes a communication interface (such as an HVCI routing interface or an equivalent lower-level machine communication interface) for communicating with the target vehicle's OBD system.

[0031] Figure 1 A schematic flowchart illustrating a remote joint debugging method for vehicle model debugging according to an embodiment of this application is shown. Figure 2 This diagram illustrates a timing flow for page data debugging during remote integration testing according to an embodiment of this application. Figure 1 and Figure 2 As shown, this remote debugging method for vehicle model debugging may include: S210 sends the target vehicle's data information to the remote control terminal.

[0032] The diagnostic equipment terminal first establishes a communication connection with the target vehicle through its OBD interface to read the vehicle's basic data information. This data includes at least the Vehicle Identification Number (VIN), vehicle version number, ECU (Electronic Control Unit) list, and current fault codes. After obtaining this data, the diagnostic equipment terminal encapsulates it into a unified data frame and sends it to the remote control terminal via the established TCP (Transmission Control Protocol) communication connection. Upon receiving this data, the remote control terminal loads the corresponding vehicle diagnostic program and determines the subsequent diagnostic execution strategy.

[0033] S220 receives page data sent by the remote control terminal.

[0034] Page data is preferably in JSON (JavaScript Object Notation) format.

[0035] In this embodiment, the diagnostic device terminal receives a unified data frame sent by the remote control terminal via a page data channel connection, and parses the type field and data area from the unified data frame. After receiving the unified data frame, the diagnostic device terminal determines the value of the type field. If the type field indicates a page data type, it parses the data area to obtain the page JSON data.

[0036] S230 displays the actual diagnostic page corresponding to the page data on the local user interface and collects the user's interaction with the actual diagnostic page.

[0037] After obtaining the page data, the diagnostic device terminal renders and displays the corresponding actual diagnostic page on the local user interface.

[0038] The diagnostic service process of the diagnostic device terminal forwards page data to the main process user interface for rendering and display via an inter-process communication mechanism. Preferably, the diagnostic service process forwards page data to the Android main process UI via Binder or AIDL (Android Interface Definition Language) inter-process communication mechanism. The main process UI utilizes the existing page rendering logic on the diagnostic device terminal to display the actual diagnostic page corresponding to the page data on the local user interface.

[0039] In one example, when the vehicle diagnostic program on the remote control terminal reaches the next diagnostic step, "Read Engine Data Stream," the remote control terminal generates corresponding diagnostic page JSON data. This data describes a page containing a display control for "Read Engine Data Stream," editing areas for data items such as "RPM," "coolant temperature," and "throttle opening," as well as "Refresh" and "Back" buttons. The main process UI of the diagnostic device terminal receives this JSON data and renders the actual diagnostic page for the user to view and interact with.

[0040] After displaying the actual diagnostic page, the diagnostic device terminal collects user interactions with that page. These interactions include, but are not limited to, clicking buttons, selecting options, entering data, swiping pages, and returning to the previous page. When the user interacts with the main UI, the main UI captures these actions and generates the corresponding interaction results.

[0041] S240 transmits the diagnostic status information generated based on the interactive operation back to the remote control terminal, so that the remote control terminal can continue to execute the vehicle diagnostic program according to the diagnostic status information.

[0042] The diagnostic equipment terminal generates diagnostic status information based on user interactions and transmits this information back to the remote control terminal. The diagnostic status information includes the results of user interactions and the current execution status of the diagnostic process.

[0043] The main UI process sends diagnostic status information back to the diagnostic service process via Binder or AIDL cross-process communication mechanisms. The diagnostic service process encapsulates the diagnostic status information in a unified data frame format and sends it back to the remote control terminal via the communication connection. The remote control terminal then continues to execute the vehicle diagnostic program based on the received diagnostic status information.

[0044] The remote debugging method for vehicle models provided in this application executes diagnostic decisions through a remote control terminal, driving the Android device to display real pages and collect real interactions. This allows bugs that were originally only exposed during Android runtime, such as abnormal page switching, disordered interface states, and failure to advance the process after clicking a button, to be quickly reproduced and fixed. After modifying the vehicle logic on the PC, vehicle engineers can update the local diagnostic program loaded on the diagnostic device terminal, enabling the rapid repair and resolution of problems that would have occurred during the local diagnostic program's runtime, thus improving the user experience.

[0045] The remote diagnostic mode can be selectively enabled by the user on the diagnostic device terminal. For example, if problems are encountered when performing the local diagnostic mode, the remote diagnostic mode can be enabled. When the remote diagnostic mode is enabled, the vehicle engineer can monitor the execution process on the PC and fix any abnormalities in a timely manner.

[0046] The remote debugging method for vehicle model debugging provided in this application embodiment can facilitate vehicle engineers to quickly debug and repair the vehicle diagnostic process.

[0047] In one implementation, such as Figure 3 As shown, the procedure before step S210 also includes: S201, Display mode selection options. Options include at least remote debugging mode and local diagnostic mode.

[0048] After the diagnostic equipment terminal is started or enters the main diagnostic interface, mode selection options are displayed on its user interface.

[0049] Mode selection options can be presented in the form of buttons, sliders, drop-down menus, or checkboxes for users to select and switch between.

[0050] S202, obtain the mode selection instruction input by the user.

[0051] Users input mode selection commands on the diagnostic device terminal via touchscreen clicks, physical button selections, or other operations. The diagnostic device terminal then receives these mode selection commands.

[0052] S203, when the mode selection command indicates remote debugging mode, triggers a remote diagnostic request.

[0053] In one example, when the remote debugging mode is indicated, the diagnostic device terminal can set the remote debugging flag to the enabled state. This remote debugging flag is used to identify the current operating mode of the diagnostic device terminal: the flag being enabled indicates that it is in remote debugging mode, and the flag being disabled indicates that it is in local diagnostic mode.

[0054] S204, shut down the local diagnostic process, start the local TCP service, and send a communication connection request to establish a communication connection with the remote control terminal.

[0055] In response to a preset startup event (such as a user clicking the "Remote Debugging Mode" option button or receiving a startup signal from the remote control terminal), the diagnostic device terminal closes the currently running local diagnostic process. Closing the local diagnostic process prevents interference between the local and remote debugging processes, ensuring that the diagnostic device terminal in remote debugging mode only acts as the actual execution terminal of the remote control terminal, and does not independently perform vehicle model logic calculations. Subsequently, the diagnostic device terminal starts the local TCP service and sends a communication connection request to the remote control terminal to establish a communication connection.

[0056] In this embodiment of the application, two independent connections can be established between the diagnostic device terminal and the remote control terminal: (1) Page data channel connection (also known as ordinary connection) is used to receive page data, start data, and exit data sent by the remote control terminal, as well as to send the page interaction results back to the remote control terminal; (2) OBD data channel connection (also known as OBD command connection) is used to report data information, diagnostic status information and interactive feedback information collected from the target vehicle's OBD system to the remote control terminal.

[0057] The two connections are independent of each other, so that page data transmission and OBD data transmission do not interfere with each other, avoiding the impact of OBD data acquisition waiting on page debugging, which helps to improve the efficiency of joint debugging.

[0058] In one implementation, step S220 includes: receiving a unified data frame sent by a remote control terminal. The unified data frame includes at least a length field, a type field, and a data area. Page data is parsed from the unified data frame.

[0059] In one example, a uniform data frame includes at least a 4-byte length field, a 1-byte type field, and an N-byte data area. The length field is little-endian and its value is the total number of bytes in the length field itself, the type field, and the data area. The type field indicates the service type of the current data frame.

[0060] In this embodiment, all data in the unified data frame is encapsulated using the same frame format to ensure data format consistency and parsability. Whether it's OBD data or interaction results reported by the diagnostic device terminal, or page data or control commands issued by the remote control terminal, all are transmitted using this unified data frame format.

[0061] After receiving a unified data frame, the diagnostic device terminal first reads the length field to determine the boundaries of the entire data frame. Specifically, the value of the length field is the total number of bytes in the entire data frame (including the length field itself, the type field, and the data area). The diagnostic device terminal uses this value to determine whether the data frame has been completely received.

[0062] The diagnostic device terminal reads the type field and determines the service type of the current data frame based on the value of the type field. When the type field indicates that the current data frame is "page data", the diagnostic device terminal extracts the page data from the data area.

[0063] In one implementation, in a unified data frame: the length field occupies 4 bytes, uses little-endian order, and its value is the total number of bytes of the length field itself, the type field, and the data area; the type field occupies 1 byte and is used to indicate the service type of the current data frame. Service types include handshake, vehicle model loading, startup, exit, page data, OBD command, collection information, vehicle information, and secure access.

[0064] In one example, the format of the uniform data frame is as follows: (1) Length field The length field occupies 4 bytes and is stored in little-endian order. The value of the length field is the total number of bytes in the length field itself (4 bytes), the type field (1 byte), and the data area (N bytes). Little-endian storage means that the least significant byte of multi-byte data is stored at the lowest address, and the most significant byte is stored at the highest address.

[0065] In this embodiment, both the remote control terminal (Windows / MacOS PC, x86 / x86-64 architecture) and the diagnostic device terminal (Android device, ARM architecture, default little-endian) use little-endian, allowing direct transmission without byte order conversion, thus improving data transmission efficiency.

[0066] (2) Type field The type field occupies 1 byte and is used to indicate the service type of the current data frame. Service types can include, but are not limited to, handshake, vehicle model loading, startup, exit, page data, OBD commands, collected information, vehicle information, etc.

[0067] (3) Data area The data area occupies N bytes and is used to carry the actual business data. The specific content of the data area is determined by the business type indicated by the type field. When the type field is "page data", the data area contains the page's JSON data; When the type field is "collected information", the data area contains real-time vehicle operating parameter data; When the type field is "Vehicle Information", the data area carries vehicle identification information such as the VIN code.

[0068] With the aforementioned unified data frame format, the diagnostic equipment terminal can accurately identify the service type of the received data frame and execute the corresponding processing logic accordingly.

[0069] In one implementation, the method further includes: obtaining a debugging log when the diagnostic status information indicates that the diagnostic has ended; and sending the debugging log to a remote control terminal.

[0070] If the diagnostic status information indicates that the diagnostic process is complete, the current diagnostic process is finished. The diagnostic process can also be completed, for example, when the user clicks the "Exit Diagnostics" button or when the remote control terminal sends an exit command. The diagnostic device terminal obtains the debugging logs for this remote debugging session.

[0071] Debug logs should record at least the following: message direction (received / sent), data type (corresponding type field), data length, timestamp, and a partial data content summary. For OBD command-related data frames, the logs should also record in detail the raw command data actually sent by the Android device to the lower-level device and the raw return results received from the lower-level device, including the actual response time and whether a timeout occurred.

[0072] The diagnostic equipment terminal encapsulates the debugging logs and sends them to the remote control terminal. Vehicle engineers can not only view the real-time page display on the Android device on their PCs, but also simultaneously compare communication data and interaction results, thus accurately pinpointing whether the bug is caused by a page logic error, an OBD command timing issue, or an abnormal response from the lower-level machine.

[0073] The remote control terminal stores the received debugging logs, which can be used as samples in the subsequent vehicle logic development process to adjust the subsequent model; it can also be used as model samples for diagnostic strategy development to improve the accuracy and efficiency of the diagnostic strategy.

[0074] This application provides a remote debugging method for vehicle model testing, applied to a remote control terminal, preferably a Windows or macOS computer running a vehicle diagnostic program. This vehicle diagnostic program is developed and maintained by vehicle engineers in a Windows or macOS environment and contains complete vehicle diagnostic logic. In this remote debugging method for vehicle model testing, the remote control terminal is responsible for running the complete vehicle diagnostic program, undertaking the core role of logical operations and flow control, while the Android diagnostic device only serves as the actual execution terminal. Figure 4 As shown, this remote debugging method for vehicle model debugging includes: S410 receives data information from the target vehicle.

[0075] The remote control terminal receives data information about the target vehicle sent by the diagnostic equipment terminal via the OBD data channel. This data information is acquired by the diagnostic equipment terminal from the OBD system of the target vehicle through its communication connection.

[0076] In this embodiment, the remote control terminal receives unified data frames sent by the diagnostic device terminal via the OBD data channel and parses the data information from the unified data frames. The remote control terminal first reads the length field to determine the data frame boundaries, then reads the type field to determine the service type, and finally extracts the data information from the data area.

[0077] The data information includes at least one or more of the following: vehicle data information (such as real-time operating parameters such as vehicle speed, engine speed, and coolant temperature), fault code information (such as diagnostic fault codes DTC), and diagnostic status information (such as current diagnostic progress and communication status of each ECU).

[0078] S420 determines the diagnostic execution strategy based on data information.

[0079] The remote control terminal inputs the received data information into the vehicle diagnostic program, which then determines the diagnostic execution strategy based on the data information.

[0080] Specifically, the vehicle diagnostic program determines the fault type of the target vehicle based on fault codes, vehicle operating parameters, and other information in the data, and generates a corresponding diagnostic execution strategy based on the fault type. The diagnostic execution strategy includes at least one diagnostic step arranged in execution order.

[0081] For example, when the remote control terminal receives a fault code P0300 (random / multi-cylinder misfire detection) reported by the diagnostic equipment terminal, the vehicle diagnostic program determines the diagnostic execution strategy based on the fault code, including the following diagnostic steps: the first step is to "read the misfire counters of each cylinder", the second step is to "check the status of the ignition system", and the third step is to "check the status of the fuel system".

[0082] S430, in accordance with the diagnostic execution strategy, sends the page data of the target page to the diagnostic device terminal.

[0083] The remote control terminal determines the target page corresponding to the diagnostic step to be executed according to the diagnostic execution strategy, and sends the page data of the target page to the diagnostic device terminal.

[0084] S440 receives diagnostic status information.

[0085] The remote control terminal receives diagnostic status information transmitted back from the diagnostic device terminal via a page data channel. This diagnostic status information is generated based on the user's interactive actions on the currently displayed diagnostic page.

[0086] Diagnostic status information includes user interaction results (such as the user clicking the "Read" button, selecting an option, or entering a specific value) and diagnostic process status (such as the current step being completed, the current step being executed, or the diagnosis being completed).

[0087] S450, determine the next execution step based on diagnostic status information.

[0088] The remote control terminal inputs the received diagnostic status information into the vehicle diagnostic program, and the vehicle diagnostic program determines the next execution step based on the diagnostic status information.

[0089] In this embodiment, the remote control terminal determines different next execution steps based on different diagnostic status information: If the diagnostic status information indicates that the current step has been completed and the user has selected "Continue", the remote control terminal determines the next step in the diagnostic execution strategy as the next execution step; If the diagnostic status information indicates that the user has selected "skip" a step, the remote control terminal determines that the step following that step is the next step to be executed. If the diagnostic status information indicates that the current step has been completed and the user has selected "Exit", the remote control terminal will determine to exit the diagnostic process. If the diagnostic status information indicates that the diagnostic process is complete, the remote control terminal will end the diagnostic process.

[0090] S460, send the page data corresponding to the next execution step to the diagnostic device terminal.

[0091] After determining the next execution step, the remote control terminal encapsulates the page data corresponding to the next execution step in a unified data frame format and sends it to the diagnostic device terminal through the page data channel connection.

[0092] Repeat the above steps until all steps in the diagnostic execution strategy have been completed or the user voluntarily exits.

[0093] The vehicle diagnostic program on the remote control terminal runs completely on the PC. The diagnostic device terminal, as the actual execution terminal, provides the capabilities of real page rendering, user interaction collection, and OBD data collection. The two work together through two independent data channels, enabling vehicle engineers to directly observe the actual running performance on the Android diagnostic device while developing and fixing vehicle bugs on the PC.

[0094] In one example, such as Figure 5As shown, during OBD command debugging, the remote control terminal sends an OBD command data frame. When the diagnostic device terminal parses the frame, the first four bytes (little-endian) of the data area indicate the timeout period for receiving the command. It then calls the existing HVCI routing interface to send the command and waits for a response from the lower-level machine within the timeout period. If the lower-level machine does not return, returns an empty frame, or a communication error occurs, the diagnostic device terminal still sends an empty response frame back to the remote control terminal (the data area is empty or filled with a specific error code), clearly indicating to the remote control terminal that the command has been processed and preventing the PC-side vehicle logic from getting stuck due to waiting for a response.

[0095] To avoid prolonged occupation of diagnostic equipment resources, the remote debugging mode adopts an on-demand start-up and on-demand shutdown strategy. The diagnostic equipment terminal only closes the local diagnostic process and starts the local TCP service after the user explicitly selects the remote debugging mode; upon receiving an exit command or session timeout, it closes the TCP service and restores the local diagnostic mode to its available state.

[0096] This application employs a dual TCP connection architecture: the page data connection carries page data and interaction results, while the OBD command connection carries lower-level machine commands and return results. The two connections operate independently and do not block each other. For example, if an OBD command needs to wait 500 milliseconds for a response from the lower-level machine, page data transmission and user interaction can still proceed normally through the normal connection. During this period, engineers can observe details such as whether the page experiences lag or whether the spinning animation is normal.

[0097] Within an Android diagnostic device, the diagnostic service process (responsible for TCP connection maintenance and data frame parsing) and the main UI process (responsible for page rendering and interaction acquisition) forward data via Binder, AIDL, or an equivalent cross-process mechanism. This design reuses the device's existing process architecture, eliminating the need for large-scale modifications to the main UI process and resulting in low implementation costs.

[0098] The following is a complete example illustrating the working process of an embodiment of this application: Example application scenario: When a vehicle engineer discovers on a PC that a certain vehicle model is running on an Android diagnostic device, the page does not refresh after clicking the "Refresh" button on the "Read Engine Data Stream" page. The engineer needs to locate and fix this bug.

[0099] Implementation process: The engineer connects the Android diagnostic device (diagnostic device terminal) to the target vehicle via the OBD interface and selects "remote debugging mode" on the device; The Android diagnostic device shuts down the local diagnostic process, starts the local TCP service, and establishes a page data channel connection and an OBD data channel connection with the PC (remote control end). When the PC-based vehicle diagnostic program reaches the "Read Engine Data Stream" step, it sends the corresponding page JSON data to the Android diagnostic device through the page data channel. The Android diagnostic device renders and displays the actual diagnostic page, "Read Engine Data Stream". When the engineer clicked the "refresh" button on the Android device, the page did not refresh (bug reproduction); Android diagnostic devices send the interaction result of "clicking the refresh button" back to the PC as diagnostic status information; The vehicle engineer analyzed the interaction results and debugging logs on the PC and found that there was a timing problem in the page refresh logic. He then modified the vehicle diagnostic program code on the PC. The diagnostic process is re-executed on the PC, and the "Read Engine Data Stream" page data is sent to the Android diagnostic device again. The Android diagnostic device re-displays the page, and the engineer clicks the "Refresh" button again to verify the repair effect; Repeat the above steps until the bug is completely fixed.

[0100] Through the above process, vehicle engineers can quickly locate and fix bugs that only occur during actual Android operation on the PC without having to migrate the vehicle logic to the Android platform or rely on post-event analysis methods such as screen recording, logs, and manual reproduction.

[0101] This application also provides a remote debugging system for vehicle model debugging, such as... Figure 6 As shown, it includes: The diagnostic equipment terminal 610 communicates with the OBD interface of the target vehicle. The remote control terminal 620 is remotely connected to the diagnostic equipment terminal 610. The diagnostic equipment terminal 610 is loaded with a local diagnostic program and a remote diagnostic program, and the local diagnostic program and the remote diagnostic program use the same data frame.

[0102] The local diagnostic program is used to independently perform vehicle diagnostics in local diagnostic mode, while the remote diagnostic program is used to work collaboratively with the remote control terminal in remote debugging mode. Both the local and remote diagnostic programs use a unified data frame for data organization to ensure data format consistency between the two modes.

[0103] In one embodiment, the diagnostic device terminal 610 includes: The data information sending module 611 is used to send the data information of the target vehicle to the remote control terminal; Content receiving module 612 is used for page data sent by the remote control terminal; The page display module 613 is used to display the real diagnostic page corresponding to the page data on the local user interface and to collect the user's interaction with the real diagnostic page. Feedback module 614 is used to send back diagnostic status information generated based on interactive operation to the remote control terminal so that the remote control terminal can continue to execute the vehicle diagnostic program according to the diagnostic status information.

[0104] In one embodiment, the diagnostic device terminal 610 further includes: The mode selection module 615 is used to display mode selection options; the options include at least remote debugging mode and local diagnostic mode. The mode instruction acquisition module 616 is used to acquire the mode selection instruction input by the user; The remote trigger module 617 is used to trigger a remote diagnostic request when the mode selection command indicates that the remote joint debugging mode is selected; The remote communication module 618 is used to close the local diagnostic process, start the local TCP service, and send a communication connection request to establish a communication connection with the remote control terminal.

[0105] In one implementation, the communication connection includes at least two independent connection channels: The page data channel is used to receive page data, start data, and exit data sent from the remote control terminal, as well as to send page interaction results back to the remote control terminal. The OBD data channel is used to report data information, diagnostic status information, and interactive feedback information collected from the target vehicle's OBD system to the remote control terminal.

[0106] In one implementation, the content receiving module 612 is used to: Receive unified data frames sent by the remote control terminal. The unified data frame includes at least a length field, a type field, and a data area. Parse page data from a unified data frame; The length field occupies 4 bytes, uses little-endian order, and its value is the total number of bytes of the length field itself, the type field, and the data area. The type field occupies 1 byte and is used to indicate the service type of the current data frame. Service types include handshake, vehicle model loading, startup, exit, page data, OBD command, data acquisition, vehicle information, and secure access.

[0107] In one embodiment, the diagnostic device terminal 610 further includes: The debug log acquisition module 619 is used to acquire debug logs when the diagnostic status information indicates that the diagnostic has ended. The data information sending module 611 is also used to send debugging logs to the remote control terminal.

[0108] In one implementation, the remote control terminal 620 includes: Data receiving module 621 is used to receive data information from the target vehicle; The fault handling module 622 is used to determine the diagnostic execution strategy based on data information; The content sending module 623 is used to send page data of the target page to the diagnostic device terminal according to the diagnostic execution strategy; in, The data receiving module 621 is also used to receive diagnostic status information; The fault handling module 622 is also used to determine the next execution step based on the diagnostic status information; The content sending module 623 is also used to send the page data corresponding to the next execution step to the diagnostic device terminal.

[0109] The functions of each module in each device in the embodiments of this application can be found in the corresponding descriptions in the above methods, and will not be repeated here.

[0110] Figure 7 A structural block diagram of an electronic device according to an embodiment of this application is shown. Figure 7 As shown, the electronic device includes a memory 910 and a processor 920. The memory 910 stores instructions that can be executed on the processor 920. When the processor 920 executes the instructions, it implements the remote joint debugging method for vehicle-type debugging in the above embodiments. The number of memories 910 and processors 920 can be one or more. This electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0111] The electronic device may also include a communication interface 930 for communicating with external devices and exchanging data. The devices are interconnected using different buses and can be mounted on a common motherboard or otherwise as needed. The processor 920 can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). The bus can be divided into address buses, data buses, control buses, etc. For ease of illustration, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0112] Optionally, in a specific implementation, if the memory 910, processor 920, and communication interface 930 are integrated on a single chip, then the memory 910, processor 920, and communication interface 930 can communicate with each other through an internal interface.

[0113] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the Advanced Reduced Instruction Set Computing (RISC) machine (ARM) architecture.

[0114] This application provides a computer-readable storage medium (such as the memory 910 described above) that stores computer instructions, which, when executed by a processor, implement the method provided in this application.

[0115] Optionally, the memory 910 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the use of the electronic device according to the remote debugging method for vehicle model debugging. Furthermore, the memory 910 may include high-speed random access memory and may also include non-transient memory, such as at least one disk storage device, flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 910 may optionally include memory remotely located relative to the processor 920, and these remote memories can be connected to the electronic device for the remote debugging method for vehicle model debugging via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0116] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0117] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0118] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more (two or more) executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0119] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0120] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0121] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0122] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A remote joint debugging method for vehicle model debugging, characterized in that, The method, applied to a diagnostic device terminal, includes: Send the target vehicle's data information to the remote control terminal; Receive page data sent by the remote control terminal; Display the actual diagnostic page corresponding to the page data on the local user interface, and collect the user's interaction with the actual diagnostic page; The diagnostic status information generated based on the interactive operation is sent back to the remote control terminal so that the remote control terminal can continue to execute the vehicle diagnostic program according to the diagnostic status information.

2. The method according to claim 1, characterized in that, Before sending the target vehicle's data information to the remote control terminal, the process also includes: Display mode selection options; the options include at least remote debugging mode and local diagnostic mode; Obtain the mode selection command input by the user; When the mode selection instruction indicates the remote debugging mode, a remote diagnostic request is triggered; The local diagnostic process is shut down, and the local TCP service is started, sending a communication connection request to establish a communication connection with the remote control terminal.

3. The method according to claim 2, characterized in that, The communication connection includes at least two independent connection channels: The page data channel is used to receive page data, start data, and exit data sent by the remote control terminal, and to send page interaction results back to the remote control terminal. The OBD data channel is used to report data information, diagnostic status information, and interactive feedback information collected from the target vehicle's OBD system to the remote control terminal.

4. The method according to any one of claims 1 to 3, characterized in that, The receipt of page data sent by the remote control terminal includes: Receive a unified data frame sent by the remote control terminal, wherein the unified data frame includes at least a length field, a type field, and a data area; The page data is parsed from the unified data frame; In the unified data frame: the length field occupies 4 bytes, adopts little-endian order, and its value is the total number of bytes of the length field itself, the type field, and the data area; The type field occupies 1 byte and is used to indicate the service type of the current data frame. The service type includes handshake, vehicle model loading, startup, exit, page data, OBD command, collection information, vehicle information, and secure access.

5. The method according to claim 1, characterized in that, Also includes: If the diagnostic status information indicates that the diagnostic is complete, obtain the debug log; The debug log is sent to the remote control terminal.

6. A remote joint debugging method for vehicle model debugging, characterized in that, Applications in remote control terminals include: Receive data information from the target vehicle; Based on the data information, a diagnostic execution strategy is determined; According to the diagnostic execution strategy, the page data of the target page is sent to the diagnostic device terminal; Receive diagnostic status information; The next execution step is determined based on the diagnostic status information; Send the page data corresponding to the next execution step to the diagnostic device terminal.

7. A remote joint debugging system for vehicle model debugging, characterized in that, include: The diagnostic equipment terminal communicates with the OBD interface of the target vehicle. The remote control terminal is remotely connected to the diagnostic equipment terminal; The diagnostic device terminal is loaded with a local diagnostic program and a remote diagnostic program, and the local diagnostic program and the remote diagnostic program use the same data frame.

8. The system according to claim 7, characterized in that, The diagnostic equipment terminal includes: The data information sending module is used to send the target vehicle's data information to the remote control terminal; A content receiving module is used for receiving page data sent by the remote control terminal; The page display module is used to display the actual diagnostic page corresponding to the page data on the local user interface, and to collect the user's interactive operations on the actual diagnostic page; The feedback module is used to send back the diagnostic status information generated based on the interactive operation to the remote control terminal, so that the remote control terminal can continue to execute the vehicle diagnostic program according to the diagnostic status information.

9. The system according to claim 7, characterized in that, The remote control terminal includes: The data receiving module is used to receive data information from the target vehicle; The fault handling module is used to determine the diagnostic execution strategy based on the data information; The content sending module is used to send page data of the target page to the diagnostic device terminal according to the diagnostic execution strategy; in, The data receiving module is also used to receive diagnostic status information; The fault handling module is also used to determine the next execution step based on the diagnostic status information; The content sending module is also used to send the page data corresponding to the next execution step to the diagnostic device terminal.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 6.

Images