A method of rewriting a diagnostic request and an electronic device

Abstract

The application relates to the technical field of request rewriting, and discloses a diagnosis request rewriting method and an electronic device, the method comprising the following steps: obtaining a diagnosis request; if the intention type of the diagnosis request is a reading type, rewriting the diagnosis request in a first processing mode when the diagnosis request meets verification conditions, and rewriting the diagnosis request in a second processing mode when the diagnosis request does not meet the verification conditions; if the intention type of the diagnosis request is a writing type or a fuzzy type, rewriting the diagnosis request in the second processing mode; rewriting the diagnosis request in the first processing mode comprises the following steps: reading first rewriting information based on to-be-rewritten information of the diagnosis request, and rewriting the diagnosis request; rewriting the diagnosis request in the second processing mode comprises the following steps: generating clarification information based on the to-be-rewritten information of the diagnosis request; and rewriting the diagnosis request based on second rewriting information corresponding to the clarification information. Through the above method, the safety of diagnosis request rewriting is improved.

Description

Technical Field

[0001] This application relates to the field of request rewriting technology, specifically to a method and electronic device for rewriting diagnostic requests. Background Technology

[0002] With the application of artificial intelligence technology, repair technicians often interact with intelligent diagnostic assistants via voice or text. To improve communication efficiency, technicians habitually use a large number of abbreviations and pronouns during operations, such as "check again," "clear this," and "read the data." The intelligent assistant needs to semantically complete and rewrite these incomplete user requests to fill in the missing information and restore the complete operation instructions so that downstream services can accurately understand and execute them.

[0003] In existing technologies, rewriting schemes based on dialogue history context are typically used for natural language input containing omissions and pronouns. Specifically, the rewriting process directly utilizes the historical conversation information from the most recent rounds or several rounds, extracting entities such as vehicle identifiers, fault codes, and component names through dialogue context understanding technology. These extracted entities are then directly filled into the missing slots of the current request, thereby generating a complete query statement. Subsequently, this rewritten information is directly written into the execution parameters for direct use by downstream semantic understanding or task execution modules.

[0004] However, in the specialized scenario of automotive diagnostics, this simple method of rewriting based on historical session information can lead to errors in object identification, altering the state of vehicle components and potentially causing the loss of critical vehicle data, hardware damage, or even safety accidents. For example, an automotive diagnostic scenario may involve multiple types of information, including session-bound vehicles, physically connected vehicles, dialogue memories, and the current interface state. If a technician is discussing a fault in vehicle A, but the actual physical connection is to vehicle B, clearing the connection might mistakenly insert vehicle A's information into the operation instructions for vehicle B, causing cross-referencing and resulting in incorrect diagnosis or execution. In severe cases, this could lead to vehicle damage or safety accidents.

[0005] Therefore, improving the security of diagnostic request rewriting has become an urgent technical problem to be solved. Summary of the Invention

[0006] In view of the above problems, embodiments of this application provide a method and electronic device for rewriting diagnostic requests, which solves the problem that the security of rewriting diagnostic requests in the prior art needs to be improved.

[0007] According to one aspect of the embodiments of this application, a method for rewriting a diagnostic request is provided. The method includes: obtaining a diagnostic request; if the intent type of the diagnostic request is a read type, then rewriting the diagnostic request in a first processing method when the diagnostic request meets the verification conditions, and rewriting the diagnostic request in a second processing method when the diagnostic request does not meet the verification conditions; if the intent type of the diagnostic request is a write type or an ambiguous type, then rewriting the diagnostic request in the second processing method; wherein, rewriting the diagnostic request in the first processing method includes: reading first rewriting information based on the information to be rewritten in the diagnostic request; rewriting the diagnostic request based on the first rewriting information; and rewriting the diagnostic request in the second processing method includes: generating clarification information based on the information to be rewritten in the diagnostic request; obtaining second rewriting information corresponding to the clarification information; and rewriting the diagnostic request based on the second rewriting information.

[0008] In one alternative approach, if the intent type of the diagnostic request is read, then before rewriting the diagnostic request using a first processing method when the diagnostic request meets the verification conditions, and before rewriting the diagnostic request using a second processing method when the diagnostic request does not meet the verification conditions, after obtaining the diagnostic request, the method further includes: reading multiple information sources, wherein the multiple information sources include at least any two of the following: the vehicle identifier bound to the session corresponding to the diagnostic request, the vehicle identifier read through the diagnostic interface connected to the target vehicle, the historical session data of the session corresponding to the diagnostic request, and the diagnostic request itself. The data includes the page currently navigated to by the corresponding session, the function identifier of the function currently being executed by the session corresponding to the diagnostic request, and the diagnostic process data being executed by the session corresponding to the diagnostic request. The information from multiple information sources is compared to obtain the comparison results. If the comparison results indicate that the information from multiple information sources is consistent, and the information to be rewritten in the diagnostic request exists in all multiple information sources, then the diagnostic request meets the verification conditions. If the comparison results indicate that the information from multiple information sources is inconsistent, or the information to be rewritten in the diagnostic request does not exist in the multiple information sources, then the diagnostic request does not meet the verification conditions.

[0009] In one optional approach, if the comparison results indicate inconsistencies between the information from multiple information sources, or if the information to be rewritten in the diagnostic request does not exist in the multiple information sources, then the diagnostic request is determined to not meet the verification conditions. This includes: if the comparison results indicate inconsistencies between the information from multiple information sources, then the diagnostic request is determined to not meet the verification conditions, and the clarification type of the diagnostic request is determined to be a conflict option clarification type; if the information to be rewritten in the diagnostic request does not exist in the multiple information sources, then the diagnostic request is determined to not meet the verification conditions, and the clarification type of the diagnostic request is determined to be a missing required slot type; if the intent type of the diagnostic request is a write type or an ambiguous type, then the diagnostic request is rewritten using a second processing method, including: if the intent type of the diagnostic request is a write type or an ambiguous type, then the clarification type of the diagnostic request is determined to be a write object confirmation type, and the diagnostic request is rewritten using the second processing method; generating clarification information based on the information to be rewritten in the diagnostic request includes: generating clarification information based on the information to be rewritten in the diagnostic request and the clarification type.

[0010] In one alternative approach, if the intent type of the diagnostic request is read-type, the diagnostic request is rewritten using a first processing method when the diagnostic request meets the verification conditions, and rewritten using a second processing method when the diagnostic request does not meet the verification conditions. After obtaining the diagnostic request, the method further includes: determining the intent type of the diagnostic request according to a preset rule vocabulary; and / or determining the intent type of the diagnostic request according to a preset model.

[0011] In one optional approach, after reading multiple information sources, the method further includes: determining consistent information from the multiple information sources as consistency information; after generating clarification information based on the information to be rewritten in the diagnostic request, and before obtaining the second rewritten information corresponding to the clarification information, the method further includes: obtaining vehicle snapshot data at the current moment; after obtaining the second rewritten information corresponding to the clarification information, and before rewriting the diagnostic request based on the second rewritten information, the method further includes: obtaining vehicle verification data at the current moment; rewriting the diagnostic request based on the second rewritten information, including: if the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read, generating third rewritten information based on the consistency information and the second rewritten information. and base The diagnostic request is rewritten based on the third rewriting information; if the vehicle verification data is consistent with the vehicle snapshot data, the diagnostic request is rewritten based on the second rewriting information when the intent type of the diagnostic request is write-type or fuzzy-type.

[0012] In one optional approach, if the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read-type, third rewriting information is generated based on the consistency information and the second rewriting information, and the diagnostic request is rewritten based on the third rewriting information. This includes: if the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read-type, third rewriting information is generated based on the consistency information and the second rewriting information; if all the information to be rewritten in the diagnostic request exists in the third rewriting information, then the diagnostic request is rewritten based on the third rewriting information; if the information to be rewritten in the diagnostic request does not exist in the third rewriting information, then the second processing is performed again. The diagnostic request is rewritten using the following method: If the vehicle verification data is consistent with the vehicle snapshot data, and the intent type of the diagnostic request is write-type or fuzzy-type, the diagnostic request is rewritten based on the second rewriting information, including: if the vehicle verification data is consistent with the vehicle snapshot data, and the intent type of the diagnostic request is write-type or fuzzy-type, determining whether all the information to be rewritten in the diagnostic request exists in the second rewriting information; if all the information to be rewritten in the diagnostic request exists in the second rewriting information, the diagnostic request is rewritten based on the second rewriting information; if the information to be rewritten in the diagnostic request does not exist in the second rewriting information, the diagnostic request is rewritten again using the second processing method.

[0013] In one optional approach, if the intent type of the diagnostic request is read, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten using a first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten using a second processing method, including: if the intent type of the diagnostic request is read, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten using the first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten using the second processing method within a first preset number of times; if the intent type of the diagnostic request is write or ambiguous, then the diagnostic request is rewritten using the second processing method, including: if the intent type of the diagnostic request is write or ambiguous, the diagnostic request is rewritten using the second processing method within a second preset number of times; wherein the first preset number of times is greater than the second preset number of times.

[0014] In one alternative approach, the method further includes: synchronously activating a timer when generating clarification information; if the second rewritten information corresponding to the clarification information is not obtained when the timer reaches a preset time value, generating a prompt for re-entry; and rewriting the diagnostic request based on the second rewritten information, including: if the second rewritten information corresponding to the clarification information is obtained before the timer reaches the preset time value, then rewriting the diagnostic request based on the second rewritten information.

[0015] In one optional approach, after obtaining the diagnostic request, the method further includes: if the diagnostic request contains multiple pieces of information to be rewritten, then splitting the diagnostic request into multiple diagnostic sub-requests based on the multiple pieces of information to be rewritten; if the intent type of the diagnostic request is a read-type request, then rewriting the diagnostic request using a first processing method when the diagnostic request meets the verification conditions, and rewriting the diagnostic request using a second processing method when the diagnostic request does not meet the verification conditions, including: for any one of the multiple diagnostic sub-requests, if the intent type of the current diagnostic sub-request is a read-type request, then rewriting the current diagnostic sub-request using the first processing method when the current diagnostic sub-request meets the verification conditions, and rewriting the current diagnostic sub-request using the second processing method when the current diagnostic sub-request does not meet the verification conditions. If the intent type of the diagnostic request is write-type or fuzzy-type, then the diagnostic request is rewritten using a second processing method, including: for any one of multiple diagnostic sub-requests, if the intent type of the current diagnostic sub-request is write-type or fuzzy-type, then the current diagnostic sub-request is rewritten using the second processing method; wherein, rewriting the current diagnostic sub-request using a first processing method includes: reading first rewriting information based on the information to be rewritten in the current diagnostic sub-request; rewriting the current diagnostic sub-request based on the first rewriting information; rewriting the current diagnostic sub-request using a second processing method includes: generating clarification information based on the information to be rewritten in the current diagnostic sub-request; obtaining second rewriting information corresponding to the clarification information; and rewriting the current diagnostic sub-request based on the second rewriting information.

[0016] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement a method for rewriting diagnostic requests as described above.

[0017] This application embodiment obtains a diagnostic request. If the intent type of the diagnostic request is write-type or ambiguous, the diagnostic request is rewritten using a second processing method to classify and isolate high-risk operations involving changes in the state of vehicle components. Based on this, clarification information is generated based on the information to be rewritten in the diagnostic request, and second rewritten information corresponding to the clarification information is obtained. This forces the user to provide explicit confirmation of the operation object, making it impossible to rely solely on historical session information to automatically fill in execution parameters. This effectively solves the problem of vehicle-to-vehicle semantics in the prior art where blind rewriting leads to the misuse of vehicle A information for vehicle B operations, avoiding the loss of critical vehicle data, hardware damage, and safety accidents caused by object identification errors. Furthermore, if the intent type of the diagnostic request is read-type, the diagnostic request is rewritten using a first processing method when the diagnostic request meets the verification conditions. This allows for the automatic rewriting of low-risk read operations when the verification conditions are met, implementing differentiated processing strategies based on risk levels. This ensures both processing efficiency and the security of diagnostic request rewriting.

[0018] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0019] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating the method for rewriting diagnostic requests provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating another method for rewriting a diagnostic request provided in an embodiment of this application is shown; Figure 3 This illustration shows a schematic diagram of the structure of a diagnostic request rewriting device provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0021] The diagnostic request rewriting method provided in this application is applicable to rewriting diagnostic requests in multiple fields, and is particularly applicable to rewriting diagnostic requests in the automotive field.

[0022] Figure 1 This diagram illustrates a flowchart of a diagnostic request rewriting method provided in an embodiment of this application. The method is executed by a diagnostic request rewriting device (hereinafter referred to as the "rewriting device"). The rewriting device can be an on-board diagnostic instrument, a server, a cloud computing platform, an edge computing device, a personal computer, a tablet computer, or a smart terminal with data processing capabilities, etc. Figure 1 As shown, the method includes steps S11 to S13: S11, Get diagnostic request.

[0023] The rewriting device receives diagnostic requests input by the user through an input interface. These requests can be natural language instructions submitted by a technician at the automotive diagnostic station via voice or text. For example, the rewriting device can collect voice signals through a microphone and use speech recognition technology to convert the speech into text, thus obtaining the diagnostic request; alternatively, the rewriting device can directly obtain the user's text-based diagnostic request through a text input device such as a touchscreen or keyboard. Diagnostic requests may contain abbreviations or pronouns, such as "check again" or "clear this," which are semantically incomplete and require subsequent steps to rewrite and complete the information.

[0024] S12, if the intent type of the diagnostic request is a read type, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten in the first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten in the second processing method.

[0025] The first step in rewriting a diagnostic request is to determine its intent type. Intent type refers to a coarse-grained classification of the diagnostic operation corresponding to the request, specifically including read, write, and fuzzy categories. Read operations do not change the persistent state of the vehicle or controller, such as querying fault codes, reading data streams, or navigating to a read-only function page. Write operations change the persistent state of the vehicle or controller, such as clearing fault codes, writing codes, parameter calibration, or flashing configurations. Fuzzy requests cannot be clearly identified based on current information, such as those with insufficient action clues or semantic ambiguity. In these cases, they are handled strictly as write requests to ensure safety.

[0026] After determining that the intent type is read-based, the rewriting device needs to further determine whether the diagnostic request meets the verification conditions. The verification conditions are used to determine whether automatic rewriting can be performed safely, and mainly include the consistency of multi-source information and the availability of the information to be rewritten.

[0027] Multi-source information includes the vehicle identifier bound to the session, the vehicle identifier read in real time through the diagnostic interface, historical session data, current page data, current function identifier, and diagnostic process data. If all these information sources are consistent, and the missing information to be rewritten in the diagnostic request (such as vehicle identifier, fault code, component name, etc.) can be extracted from this consistent information, then the verification condition is considered met; otherwise, the verification condition is not met.

[0028] If the verification conditions are met, the rewriting device rewrites the diagnostic request using the first processing method. The first processing method is the automatic rewriting method, where the rewriting device extracts relevant entity information from multi-source information and automatically fills in the missing slots of the diagnostic request, generating a semantically complete and directly executable rewritten request. For example, for the diagnostic request "Check again," if the vehicle identifier is VIN-A and the fault code is P0171 extracted from multi-source information, it is automatically rewritten as "Query the meaning of vehicle VIN-A fault code P0171." This method improves interaction efficiency and reduces user input.

[0029] If the verification conditions are not met, the rewriting device will use a second processing method to rewrite the diagnostic request. This second processing method is a clarifying rewriting method, where the rewriting device does not directly perform automatic filling but instead generates clarifying information, requiring the user to explicitly confirm or supplement any missing information, thus avoiding erroneous rewriting due to information conflicts or omissions. For example, if there are conflicts among multiple sources of information, such as historical session data pointing to a fault code for vehicle A, while the currently connected vehicle is vehicle B, the rewriting device will generate option clarification information, requiring the user to select the operation target.

[0030] S13, if the intent type of the diagnostic request is write-type or fuzzy-type, then the diagnostic request is rewritten using the second processing method.

[0031] When the rewriting device determines that the intent type of the diagnostic request is write-type or fuzzy-type, it will force the second processing method to be used regardless of whether the verification conditions are met. This is because write-type operations involve changes to the vehicle's state and are high-risk. If the device automatically rewrites the data directly based on historical information, serious consequences may result from incorrect information, such as mistakenly clearing fault codes or writing incorrect parameters, causing vehicle data loss or hardware damage. Therefore, for write-type or fuzzy-type requests, the rewriting device must, through clarification, force the user to provide clear confirmation of the operation object to ensure the accuracy of the rewritten request.

[0032] For example, when dealing with a diagnostic request to "clear it," even if fault code P0171 exists in the historical session data, the rewriting device will not automatically complete it to "clear fault code P0171." Instead, it will generate a clarification message: "What you want to clear is: Vehicle VIN-A / ECU=Engine / Fault Code P0171, please confirm or modify." Only after the user's explicit confirmation will the rewritten request be generated. This method effectively prevents erroneous operations caused by blind rewriting and improves the safety of the diagnostic process.

[0033] The process of rewriting the diagnostic request using the first processing method includes steps S14 to S15: S14, Read the first rewrite information based on the information to be rewritten in the diagnostic request.

[0034] The rewriting device reads the corresponding first rewriting information from multi-source information based on the information to be rewritten in the diagnostic request. The information to be rewritten refers to missing or required entity information in the diagnostic request, such as vehicle identification, Electronic Control Unit (ECU) identification, fault codes, and parameter values. The first rewriting information refers to the specific value extracted from the multi-source information that can be used to fill in the information to be rewritten. The rewriting device identifies the missing slots by parsing the semantics of the diagnostic request and then searches for the corresponding entity values ​​in the multi-source information. For example, for the diagnostic request "Check again," the rewriting device identifies the missing slot as a fault code and then extracts fault code P0171 from historical session data as the first rewriting information.

[0035] S15, rewrite the diagnostic request based on the first rewrite information.

[0036] The rewriting device fills the corresponding slot in the diagnostic request with the initial rewritten information, generating the rewritten complete request. The rewriting device must ensure that the filled request is semantically grammatically correct, conforms to syntax rules, and is consistent with the original meaning. Figure 1 The rewritten request can be directly output to the downstream semantic understanding service or task execution module for subsequent processing and execution. For example, based on the first rewritten information "fault code P0171" and the vehicle identification "VIN-A", the rewriting device rewrites "check again" to "query the meaning of vehicle VIN-A fault code P0171".

[0037] The diagnostic request is rewritten using the second processing method, including steps S16 to S18: S16, Generate clarification information based on the information to be rewritten in the diagnostic request.

[0038] The rewriting device generates clarification messages for the user based on the information to be rewritten in the diagnostic request and related context information. The purpose of these clarification messages is to allow the user to clearly confirm or supplement the missing operation object, thus avoiding errors caused by automatic rewriting. Clarification messages can include option lists, confirmation summaries, or specific questions. For example, for write requests, the clarification message might be, "What you want to clear is: Vehicle VIN-A / ECU=Engine / Fault Code P0171, please confirm or modify"; for cases with conflicting multi-source information, the clarification message might be, "Please confirm the query object: A. Connected vehicle VIN-A B. Memory vehicle VIN-A·P0171"; for cases with missing required fields, the clarification message might be, "Please enter the vehicle identifier to be queried." The rewriting device generates appropriate clarification messages based on the specific situation and displays them to the user.

[0039] S17, Obtain the second rewritten information corresponding to the clarification information.

[0040] The rewriting device receives the user's response to the clarification information and extracts second rewritten information from the response. The second rewritten information refers to the operation object information explicitly confirmed or supplemented by the user. The rewriting device can obtain user input through text parsing, speech recognition, option selection, etc. For example, the user can reply with confirmation, indicating agreement to the operation object in the confirmation summary; or the user can enter a specific vehicle identifier, such as "VIN-B"; or the user can select "A" from the options, indicating selection of the connected vehicle. The rewriting device extracts the corresponding entity value from the user's response as the second rewritten information.

[0041] S18, rewrite the diagnostic request based on the second rewrite information.

[0042] The rewriting device fills the corresponding slot in the diagnostic request with the second rewriting information, generating a complete rewritten request. Unlike the first processing method, the operation object information used by the rewriting device here comes directly from the user's explicit confirmation, rather than being automatically extracted from historical information, thus offering higher accuracy and security. The rewritten request can be directly output to downstream services. For example, if the user confirms "Clear vehicle VIN-A / ECU=engine / fault code P0171", the rewriting device generates "Clear vehicle VIN-A ECU engine fault code P0171" as the rewritten request.

[0043] By differentiating the intent types of diagnostic requests and employing differentiated rewriting methods for different types, the semantic crossover problem caused by blind rewriting in existing technologies is effectively solved. For read requests, automatic rewriting is allowed when verification conditions are met, improving interaction efficiency. For write or ambiguous requests, clarification-based rewriting is enforced to ensure that the operation object is explicitly confirmed by the user, avoiding erroneous operations caused by automatic filling errors and ensuring the security of the diagnostic process. Furthermore, verification and conflict detection of multi-source information further improve the accuracy of rewriting and prevent erroneous execution due to information inconsistency.

[0044] Furthermore, after rewriting the diagnostic request based on the initial rewriting information, the rewriting device also needs to perform a validity check. Specifically, after generating the rewritten request text, the rewriting device automatically executes a verification procedure to check whether the rewritten request is empty; and analyzes whether the semantics of the rewritten request matches the original diagnostic request. Figure 1The rewriting device checks whether the language expression of the rewritten request conforms to grammatical rules and is fluent and natural. If all the above checks pass, the rewriting device determines that the rewriting is successful and rewrites the diagnostic request based on the first rewriting information. If any check fails, such as a grammatical error or semantic deviation in the rewritten request, the rewriting device determines that the automatic rewriting has failed and abandons the use of the generated rewriting result. In this case, the rewriting device will adopt a rollback strategy, that is, it will not use the first rewriting information to fill in the blanks, but will directly use the original diagnostic request itself as the input for subsequent processing, to ensure that the content delivered to the downstream semantic understanding service is an accurate and valid version of the user's original input, and to prevent subsequent processing failures or misunderstandings due to rewriting errors.

[0045] To illustrate the verification conditions, in an alternative embodiment, before S12 and after S11, the method further includes steps S111 to S114: S111, Read multiple information sources, wherein the multiple information sources include at least any two of the following: the vehicle identifier bound to the session corresponding to the diagnostic request, the vehicle identifier read through the diagnostic interface connected to the target vehicle, the historical session data of the session corresponding to the diagnostic request, the page data to which the session corresponding to the diagnostic request is currently redirected, the function identifier of the function currently being executed by the session corresponding to the diagnostic request, and the diagnostic process data being executed by the session corresponding to the diagnostic request.

[0046] The rewriting device performs multi-source information reading operations to build a context foundation for verification and rewriting. Specifically, the rewriting device collects the aforementioned information from various relevant modules or storage units through internal data interfaces or buses.

[0047] The vehicle identifier bound to the session refers to the unique vehicle identifier associated with the current diagnostic session at the logical layer. It is usually selected by the technician when starting the diagnostic and is used to determine the main vehicle of the current conversation.

[0048] The vehicle identifier read through the diagnostic interface connected to the target vehicle refers to the Vehicle Identification Number (VIN) that the rewriting device reads in real time directly from the Electronic Control Unit (ECU) of the vehicle to be diagnosed through the On-Board Diagnostic (OBD) interface or other hardware connection. This identifier represents the vehicle that is actually connected at the physical level.

[0049] The historical session data corresponding to the diagnostic request refers to the summary record of the recent rounds of dialogue in the session. It includes the technician's previous instructions, system feedback, and entity information such as the diagnostic trouble code (DTC) and component name involved. It is mainly used to parse pronouns or omitted information in the current request.

[0050] The page data that the session corresponding to the diagnostic request is currently redirected to refers to the identifier of the page or view to which the user interface currently displayed by the diagnostic device belongs, reflecting the technician's current visual focus and operational context. The function identifier of the function currently being performed by the session corresponding to the diagnostic request refers to the identifier of the currently running diagnostic function module, such as "read code," "clear code," or "data stream read," used to determine the functional domain of the current operation.

[0051] The diagnostic process data executed by the session corresponding to the diagnostic request refers to the status information during the execution of the diagnostic process, such as the current node identifier of the diagnostic tree, the identifier of the currently running data reading batch, etc., which are used to locate the specific position in the process, such as "previous step" or "this code".

[0052] Depending on the specific configuration and the current actual scenario, the rewriting device reads at least two or more types of information from the various information sources listed above to ensure that subsequent verification and rewriting have sufficient basis.

[0053] By reading these multiple information sources, the rewriting device can fully perceive the context of the diagnostic site, providing a data foundation for subsequent comparison and verification, thereby avoiding misjudgments caused by incomplete information.

[0054] S112, compare the information from multiple information sources to obtain the comparison result.

[0055] The rewriting device performs cross-validation and consistency comparison on entity information read from multiple information sources. The core of the comparison is to detect whether there are semantic conflicts or information conflicts related to different vehicles. The specific comparison process includes: First, the rewriting device extracts entity information of the same dimension from multiple information sources, such as vehicle identification dimension, fault code dimension, component dimension, etc. Then, the rewriting device compares the values ​​of these dimensions in different information sources one by one to see if they are consistent. For example, the rewriting device compares the vehicle identification bound to the session with the actual connected vehicle identification read by the diagnostic interface to determine if they are the same; at the same time, it compares the fault codes mentioned in the historical session data with the fault codes of interest in the current page data or function identification to determine if there is any ambiguity. If all the information sources participating in the comparison point to the same object on the key entity and are logically consistent, the comparison result is consistent; otherwise, if any two information sources give mutually exclusive values ​​on the same entity dimension, for example, the vehicle identification bound to the session points to vehicle A, while the actual connected vehicle identification points to vehicle B, the comparison result is inconsistent, indicating that there is a conflict of evidence from multiple sources. The rewriting device comparison can effectively identify problems such as vehicle replacement, object confusion, or context mismatch that may exist at the diagnostic site, thereby eliminating high-risk conflict scenarios before rewriting.

[0056] S113. If the comparison results indicate that the information from the multiple information sources is consistent, and the information to be rewritten in the diagnostic request exists in all multiple information sources, then the diagnostic request is determined to meet the verification conditions.

[0057] The rewriting device determines whether the diagnostic request meets the verification conditions for automatic rewriting based on the comparison results and information integrity. First, the rewriting device checks whether the comparison results show consistency among multiple information sources. Only if no conflict is confirmed will the rewriting device proceed to the next step of checking whether the information to be rewritten in the diagnostic request exists in the multiple information sources.

[0058] The information to be rewritten refers to key entities that are missing or ambiguous in the diagnostic request, such as the vehicle identification number, fault code, or component name of the target vehicle. If the rewriting device can extract all the information needed to fill these missing slots from a consistent multi-channel information source, the diagnostic request is deemed to meet the verification conditions. This means that the current diagnostic request not only has a unified context but also possesses the complete information required for automatic completion, making automatic rewriting safe and accurate. For example, if the diagnostic request is "Check again," and the comparison results show that both the session-bound vehicle and the actual connected vehicle are VIN-A, and the historical session data contains fault code P0171, then the information to be rewritten, "fault code" and "vehicle," both exist, and the verification conditions are met. In this case, the rewriting device can allow the request, permitting subsequent automatic rewriting using the first processing method. This ensures that efficient automatic rewriting is only enabled under safe and controllable conditions, guaranteeing both interaction efficiency and the security of the rewriting operation.

[0059] S114. If the comparison results indicate inconsistencies between the information from multiple information sources, or if the information to be rewritten in the diagnostic request does not exist in the multiple information sources, then the diagnostic request does not meet the verification conditions.

[0060] The comparison results indicate inconsistencies between information from multiple sources. This typically signifies vehicle replacement, object switching, or contextual conflicts during the diagnostic process. For example, the technician might be discussing a fault in vehicle A, but the actual physical connection is to vehicle B, or the remembered fault code might not match the current interface focus. In such conflict scenarios, automatic rewriting would highly likely fill the request with incorrect information, leading to vehicle misoperation accidents.

[0061] The diagnostic request's rewrite information is not present in the multiple information sources. This indicates that even if there are no conflicts between the information sources, the necessary information for rewriting is lacking. For example, a technician might say "clear it," but the object referred to by "it" cannot be found anywhere, such as in the history of sessions or the current interface. In this case, the rewriting device cannot obtain accurate fill content.

[0062] Regardless of which of the above situations occurs, the rewriting device determines that the diagnostic request does not meet the verification conditions. This means that the first processing method is prohibited from being used for automatic rewriting, and it is necessary to switch to the safer second processing method, that is, to require the user to confirm or supplement through the clarification mechanism.

[0063] This step enables the rewriting device to effectively block all high-risk or insufficiently informed rewriting attempts, preventing erroneous operations caused by blind rewriting, thereby improving the security and reliability of diagnostic request processing.

[0064] For example, a technician first diagnoses a vehicle with vehicle identification number (VIN-A) at the diagnostic station, then switches to a physical connection with a vehicle with vehicle identification number (VIN-B), but does not switch the binding status within the session. At this point, the technician issues a diagnostic request to "clear the fault code." The rewritten device executes step S111, reads multiple information sources, and obtains the session-bound vehicle identifier as VIN-A, while the actual connected vehicle identifier read through the diagnostic interface is VIN-B. The historical session data records the fault code P0171 for vehicle VIN-A. Next, step S112 is executed, comparing the vehicle identifier information and finding that the session-bound vehicle identifier (VIN-A) and the actual connected vehicle identifier (VIN-B) are inconsistent. Then, step S114 is executed. Because the comparison results indicate inconsistencies between the information from the multiple information sources, the rewritten device determines that the diagnostic request does not meet the verification conditions. Therefore, the rewriting device will not mistakenly accept "clearing fault code P0171 for vehicle VIN-A" as the rewriting result. Instead, based on the determination that the verification conditions are not met, it triggers a second processing method to generate clarification information requiring the user to confirm whether the operation is performed on the currently connected vehicle VIN-B or a previously remembered vehicle VIN-A. This process effectively avoids the risk of mistakenly clearing fault codes due to vehicle mismatch, ensuring the security of vehicle data.

[0065] By introducing the reading and comparison of multiple information sources, the system achieves the perception and conflict detection of the diagnostic context. This not only accurately identifies high-risk scenarios such as inconsistencies between physically connected and logically bound vehicles, but also determines the completeness of the information required for rewriting. Automatic rewriting is only permitted when the information is consistent and complete; in cases of conflict or missing information, automatic rewriting is strictly prohibited and the process is initiated into a clarification phase. This differentiated verification strategy cuts off the path for injecting erroneous information into the rewriting process, resolving the semantic problems of vehicle mismatch and incorrect operation objects caused by blindly relying on historical information in existing technologies. This improves the safety and accuracy of human-machine interaction in automotive diagnostic scenarios, and avoids potential vehicle hardware damage or safety accidents caused by misoperation.

[0066] To guide users to accurately provide missing information or confirm the object of operation, in one optional manner, S114 includes sub-steps S1141 to S1142: S1141, if the comparison results indicate inconsistencies between information from multiple information sources, then the diagnostic request does not meet the verification conditions, and the clarification type of the diagnostic request is determined to be the conflict option clarification type.

[0067] When the rewriting device finds that information from different sources provides mutually exclusive definitions for the same entity object, it considers a conflict to exist. For example, the vehicle identifier bound to the session points to vehicle A, while the actual connected vehicle identifier read through the diagnostic interface points to vehicle B; or the fault code discussed in the historical session data is P0171, while the fault code currently displayed on the interface is P0300. This conflict indicates that the true target of the user's intent cannot be automatically determined at this time. If a forced rewriting is attempted, there is a high probability of vehicle misoperation or object errors. Therefore, the rewriting device first confirms that the diagnostic request does not meet the verification conditions and prohibits automatic rewriting. At the same time, to resolve this conflict, the rewriting device determines the clarification type as the conflict option clarification type. The subsequently generated clarification information will be presented in the form of an option list, directly showing the options of each party in the conflict to the user, forcing the user to make a choice between two or more options.

[0068] In this way, the rewriting device transforms ambiguous contextual conflicts into clear user choices, ensuring that the information upon which subsequent rewriting is based reflects the user's true intentions.

[0069] S1142, if the information to be rewritten in the diagnostic request does not exist in the multi-channel information source, then it is determined that the diagnostic request does not meet the verification conditions, and the clarification type of the diagnostic request is determined to be the missing required slot type.

[0070] Even if there are no conflicts between multiple information sources, the rewriting device may find that key information missing in the diagnostic request, such as vehicle identification, fault codes, and component names, cannot be extracted from any of the information sources. For example, if a user enters "check the data stream," but no specific vehicle or data stream item is clearly specified in the current interface or historical sessions, the rewriting device will still determine that the diagnostic request does not meet the verification conditions.

[0071] To fill in these missing information, the rewriting device will define the clarification type as the missing slot type. Subsequent clarification information will then ask follow-up questions for the specific missing slot, requiring the user to input specific parameter values.

[0072] Unlike option-based clarification, this typically involves open-ended input or targeted fill-in-the-blank guidance. By accurately locating missing required fields, the rewriting device can guide users to complete the information, avoiding rewriting failures or execution errors due to insufficient information.

[0073] Accordingly, S13 includes sub-step S131: if the intent type of the diagnostic request is a write type or an ambiguous type, then determine that the clarification type of the diagnostic request is a write object confirmation type, and rewrite the diagnostic request in the second processing method.

[0074] Regardless of whether the multi-source information is consistent, as long as the rewriting device determines that the intent type of the diagnostic request belongs to the write type (such as clearing fault codes, writing parameters) or the ambiguous type (insufficient clues, handled strictly as a write type), the highest level of security protection strategy will be activated. The rewriting device will determine the clarification type as "write object confirmation type", so that the core purpose of the clarification information is to allow the user to make a final check and confirmation of the high-risk operation to be performed and its object.

[0075] Even if the rewriting device can extract the operation target from a consistent information source, it will never directly and automatically execute the rewriting. Instead, it will generate a confirmation message containing an operation summary, such as "You are about to clear the vehicle's VIN-A fault code P0171, please confirm." Only after the user explicitly confirms will the rewriting device continue to execute subsequent rewriting steps based on the second processing method, thereby preventing accidental writing operations caused by verbal slips or residual context memory, and ensuring the safety of the vehicle's status.

[0076] Accordingly, S16 includes sub-step S161: generating clarification information based on the information to be rewritten and the clarification type of the diagnostic request.

[0077] Based on the clarification type determined in the aforementioned steps, the rewriting device constructs a specific clarification document in conjunction with the specific information to be rewritten in the diagnostic request.

[0078] The logic for generating clarification information varies depending on the clarification type. For conflict option clarification types, the rewriting device extracts different values ​​from the conflict source and generates clarification information containing a list of options, such as "There is currently a vehicle conflict. Please select the operation object: A. Remember vehicle VIN-A; B. Connected vehicle VIN-B". For missing required slot types, the rewriting device identifies the name and constraints of the missing slot and generates guiding questions, such as "Please enter the fault code you need to query". For write object confirmation types, the rewriting device summarizes all extracted operation object information and generates a confirmation summary, such as "Confirm operation: Clear fault code P0171 of vehicle VIN-A?". Through this structured generation method, the rewriting device ensures that each clarification has clear direction and operability, reducing user understanding costs and the probability of misoperation.

[0079] For example, a technician issues a diagnostic request to "clear it." At this time, the historical session data read by the rewriting device shows fault code P0171 for vehicle A, but the actual connected vehicle read by the diagnostic interface in real time is vehicle B. The rewriting device performs step S112 for comparison and finds that the remembered vehicle and the actual connected vehicle are inconsistent. Then, step S1141 is executed. Due to the conflict, the rewriting device determines that the verification condition is not met and sets the clarification type to conflict option clarification type. Then, step S161 is entered, and the rewriting device generates clarification information: "Object conflict detected. Please confirm the objects to be cleared: A. Vehicle A (P0171 in memory); B. Vehicle B (currently connected vehicle)."

[0080] By segmenting the data into those that do not meet the verification conditions and those with high-risk intentions, the rewriting device no longer asks users in general terms. Instead, it generates targeted, structured clarification information based on specific conflict, missing, or risk scenarios. This differentiated clarification strategy not only efficiently resolves information gaps and conflicts but also improves the accuracy and security of human-computer interaction, ensuring the accuracy of diagnostic request rewriting results.

[0081] To accurately predict the intent type, in one optional manner, before S12 and after S11, the method further includes step S115: determining the intent type of the diagnostic request based on a preset rule vocabulary.

[0082] The pre-defined rule dictionary refers to a mapping table of keywords and action categories that is predefined and stored in the storage medium of the rewriting device. This dictionary contains common verb phrases in the field of automotive diagnostics and their corresponding action tags. Specifically, the rule dictionary maps verbs or phrases such as read, query, view, display, and open to read-type tags, indicating that the operation will not change the vehicle's state; and maps verbs or phrases such as clear, delete, write, calibrate, flash, and reset to write-type tags, indicating that the operation will change the persistent state of the vehicle or controller.

[0083] In actual operation, the rewriting device performs word segmentation and part-of-speech tagging on the acquired diagnostic requests, extracts the core verbs or action phrases, and matches them with a rule-based vocabulary. If the diagnostic request contains keywords that match the read category tag but does not contain write category keywords, the rewriting device determines that the intent type of the diagnostic request is read; if the diagnostic request contains keywords that match the write category tag, the intent type is determined to be write.

[0084] If the diagnostic request contains both read and write keywords, or if the keywords are semantically ambiguous, the rewriting device will classify it as either a write class or an uncertain class based on the preset strict principle (uncertain classes will be treated as write classes in subsequent logic).

[0085] This rule-based approach has the advantages of high execution efficiency, logical transparency, and ease of maintenance, and is suitable for resource-constrained diagnostic equipment or scenarios with clear standard instructions.

[0086] In another alternative approach, before S12 and after S11, the method further includes step S116: determining the intent type of the diagnostic request based on a preset model.

[0087] The pre-defined model refers to a trained machine learning model or deep learning model, such as a lightweight text classification model (e.g., support vector machine, Naive Bayes) or a large language model based on natural language processing.

[0088] The rewriting device inputs the diagnostic request text into the pre-defined model. The model analyzes and calculates the semantic features of the text using its internal algorithm and weight parameters. The model not only focuses on individual keywords but also considers context, word collocation, and sentence structure for comprehensive judgment. The model's output typically includes confidence scores or probability values ​​for each category.

[0089] The rewriting device determines the intent type based on the model's output. For example, if the probability of the model outputting a write class exceeds a preset threshold (e.g., 0.8), the intent type is determined to be write; if the probability of a read class is high, it is determined to be read; if the confidence level of each category is lower than the preset threshold, or if the model determines it to be fuzzy and uncertain, the rewriting device classifies it as uncertain and processes it according to the write class logic. This model-based approach has strong semantic understanding capabilities, can handle colloquial expressions or complex compound instructions, and improves the accuracy and robustness of intent recognition.

[0090] For example, suppose the diagnostic request received by the rewriting device is "Check the engine data stream for me." The rewriting device executes step S115, retrieves "check" from the rule dictionary, finds it to be a read-type keyword, and confirms there are no write-type conflicts, thus determining the intent type to be read. Subsequently, if the technician inputs "Clear the fault codes," the rewriting device retrieves "clear" from the rule dictionary, finds it to be a write-type keyword, and immediately determines the intent type to be write. In another model-based scenario, if the technician inputs a more colloquial command, "I want to check the current RPM," the rewriting device inputs it into a preset model. The model analyzes the semantic combination of "check" and "RPM," outputs a high-confidence result for the read-type, thus determining the intent type to be read.

[0091] By providing two intent prediction methods—a rule-based vocabulary and a preset model—the rewriting device can flexibly adapt to different application scenarios and hardware conditions. The rule-based vocabulary method provides a fast and deterministic classification approach, reducing computational resource consumption and ensuring immediate response to standard commands. The preset model method introduces the semantic analysis capabilities of artificial intelligence, enabling more accurate understanding of complex and ambiguous natural language commands and reducing the false positive rate. Regardless of the method used, the rewriting device can accurately identify the risk level of the operation (read or write) before semantic understanding, thus providing a decision-making basis for subsequent action-related gating, automatic rewriting, or forced clarification, ensuring the safety and accuracy of diagnostic interactions.

[0092] To address the issue that, during the clarification wait, after the technology performs a vehicle-switching operation, the old session mistakenly merges the information after the vehicle-switching operation into the original dialogue, in one alternative approach, after S111, the method further includes: S117, determining consistent information from multiple information sources as consistent information.

[0093] While some information sources may conflict, leading to failure to meet verification conditions, others may remain consistent. For example, the vehicle identifier bound to a session may differ from the actual connected vehicle identifier, but the current interface function identifier and historical session data may point to the same functional module. The rewriting device extracts these mutually consistent and uncontradictory pieces of information and marks them as consistency information. This information represents the currently accepted unambiguous context in the diagnostic setting and serves as an important reference for subsequent auxiliary rewriting.

[0094] Accordingly, after S16 and before S17, the method further includes: S162, obtaining vehicle snapshot data at the current moment.

[0095] After sending a clarification message to the user, the rewriting device enters a suspended state awaiting a user response, immediately fixing the current vehicle identity status. Vehicle snapshot data refers to the set of vehicle identifiers captured by the rewriting device at this specific moment, including at least the vehicle identifiers bound to the session at that time, and, if a physical connection is available, the identifiers of vehicles actually connected. The rewriting device stores this snapshot data in association with the session identifier, serving as the identity anchor for this clarification request. This locks the operation object at the time the clarification request occurred, preventing the operation object from drifting during subsequent user consideration or response due to technicians changing vehicles, switching work orders, or reconnecting to the diagnostic interface.

[0096] Accordingly, after S17 and before S18, the method also includes: S172, obtaining the vehicle verification data at the current moment.

[0097] Once the rewriting device receives the user's response to the clarification information (i.e., obtains the second rewriting information), it immediately re-captures the current vehicle identity status before performing the final rewriting. Vehicle verification data refers to the set of vehicle identifiers read by the rewriting device in real time at the moment of the user's response, including session-bound vehicle identifiers and currently connected vehicle identifiers. The rewriting device obtains this data to compare with previously saved vehicle snapshot data to verify whether the operation object has changed during the clarification waiting period, thereby preventing incorrect cross-vehicle merging.

[0098] Accordingly, S18 includes sub-steps S181 to S182: S181, if the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read, the third rewrite information is generated based on the consistency information and the second rewrite information, and the diagnostic request is rewritten based on the third rewrite information.

[0099] The rewriting device first compares the vehicle verification data with the vehicle snapshot data. If they are completely consistent, it indicates that the vehicle object has not changed during the user's response period, and the environment is safe. Since the intent type is read-related (such as query, view, etc.), the operational risk is low. At this point, the rewriting device combines the previously filtered consistency information with the second rewriting information from the user's response to generate the third rewriting information.

[0100] Consistency information can provide supplementary context beyond user confirmation, such as vehicle model and system type, making the rewritten instructions more comprehensive and accurate. Ultimately, the rewriting device rewrites the original diagnostic request based on the third-party rewriting information, generating a directly executable query statement.

[0101] This approach can fully utilize contextual information while ensuring safety, thereby improving the rewriting quality of read-type operations.

[0102] S182, if the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is write-type or fuzzy-type, the diagnostic request is rewritten based on the second rewrite information.

[0103] In this step, the rewriting device also confirms that the vehicle object has not changed. However, since the intent type is write-type or fuzzy-type, it involves changes to the vehicle's state, which carries extremely high risk. Therefore, the rewriting device adopts a more stringent strategy: it completely ignores the inferences about the operation object in the previously filtered consistency information and uses only the second rewriting information explicitly replied by the user as the sole basis for the rewriting.

[0104] Even if the consistency information contains vehicle identification or other parameters, the rewriting device will not automatically fill them in. Instead, it will force all rewritten operations to originate from the user's secondary confirmation. The rewriting device will then directly generate the specified write instructions based on the second rewriting information.

[0105] This approach eliminates the possibility of erroneous operations due to residual historical context, ensuring the security of write operations.

[0106] For example, suppose the technician inputs "Check again," and the rewriting device reads that the session-bound vehicle is VIN-A, while the actually connected vehicle is VIN-B, indicating a conflict. Therefore, it enters the clarification process. The rewriting device executes step S117, determining other conflict-free information (such as vehicle model information) as consistent information. Then, step S16 is executed to generate clarification options, and immediately step S162 is executed, saving the current vehicle snapshot data as {Bound: VIN-A, Actually Connected: VIN-B}. The technician replies "Check the actually connected vehicle," and the rewriting device receives this reply as the second rewriting information. Before rewriting, the rewriting device executes step S172 to obtain the current vehicle verification data. Assuming the technician has not yet changed vehicles, the verification data is still {Bound: VIN-A, Actually Connected: VIN-B}, consistent with the snapshot. Since the request is a read request, the rewriting device executes step S181, combining the consistency information (vehicle model) and the second rewrite information (VIN-B) to generate the third rewrite information "Query VIN-B vehicle [vehicle model] data" and completes the rewrite. If the request is a write request "Clear it", and it also passes verification, the rewriting device executes step S182, generating the instruction only based on the user-confirmed "VIN-B" and not using the stored VIN-A, thereby preventing accidental operation.

[0107] By comparing vehicle snapshot data with vehicle verification data, the issue of merging old responses after changing vehicles during suspension is avoided. Simultaneously, differentiated information fusion strategies are adopted for read and write operations. Read operations fully utilize context to improve efficiency while ensuring safety, while write operations strictly rely on user confirmation to ensure safety. This improves the robustness and security of diagnostic request rewriting in complex and ever-changing workshop environments.

[0108] Furthermore, during the diagnostic request acquisition process, the rewriting device simultaneously acquires the session identifier to which the request belongs. This session identifier is a unique identifier assigned by the rewriting device to each consecutive diagnostic interaction dialogue. It is used to retrieve short-term memory related to the current dialogue from storage, i.e., extracts of recent multi-turn dialogues. Simultaneously, when the rewriting device enters the second processing mode and generates clarification information, it uses this session identifier as a key to persistently save the current state information (such as vehicle identity snapshot, consumed clarification rounds, wait start time, etc.) as a suspended state. When the rewriting device receives a user response or an object change event occurs, it also retrieves the corresponding suspended state using the session identifier to perform merging or invalidation operations. Therefore, the session identifier is crucial throughout the entire process of information reading, state suspension, state restoration, and invalidation, serving as the core link for achieving multi-turn context understanding and clarification state management.

[0109] Furthermore, after the rewriting device executes the second processing method—that is, generating clarification information based on the information to be rewritten in the diagnostic request—it enters a suspended waiting state and creates a suspended state. The suspended state is a data object persistently stored by the rewriting device using the session identifier as the key, used to record all necessary states during the clarification waiting period. The suspended state contains at least the following fields: the original diagnostic request currently being processed, the intent type corresponding to the request (read or write type), the type of clarification currently initiated (e.g., conflict option clarification, missing required slot clarification, write object confirmation, etc.), the number of clarification interaction rounds consumed, a snapshot of the vehicle identity at the current moment (including at least the session-bound vehicle identifier, and if there is a connected vehicle identifier, also including it), and the timestamp of the waiting start when the clarification was initiated. The lifespan of this suspended state is subject to a preset lifespan limit. When the rewriting device receives a user reply, receives an object change event notification (e.g., rebinding, connection change, work order switching), or detects that the suspension duration exceeds the lifespan limit, it reads the suspended state based on the session identifier and performs corresponding recovery, merging, or invalidation operations according to the event type. The introduction of the suspended state ensures that the state of the clarification interaction process is traceable, manageable, and recoverable, which is the foundation for realizing complex multi-round clarification logic.

[0110] To ensure that the rewriting result meets the requirement of information completeness, in one optional manner, S181 includes sub-steps S1811 to S1813: S1811 If the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read, the third rewrite information is generated based on the consistency information and the second rewrite information.

[0111] The rewriting device has confirmed that the vehicle identity has not changed during the clarification period, and the environment is safe. Since read-type operations (such as querying and reading data streams) are generally considered low-risk operations, their goal is to improve interaction efficiency and the richness of information obtained. Therefore, the rewriting device merges the consistency information with the second rewriting information to generate the third rewriting information. The consistency information refers to the conflict-free contextual data extracted from multiple information sources in step S117, such as the fault codes displayed on the current interface and intermediate data generated during the diagnostic process. The second rewriting information refers to the explicit response provided by the user to the clarification information, such as the specific vehicle identifier or confirmed component selected by the user. By combining the user's explicit response with the existing, conflict-free contextual information, the rewriting device can supplement more details.

[0112] For example, if the user confirms the query for vehicle B, and the consistency information contains the fault code P0300 currently displayed for vehicle B, then the third rewrite information will simultaneously contain the vehicle identifier and the fault code, thereby generating a semantically complete and informationally detailed rewritten instruction.

[0113] S1812, if all the information to be rewritten in the diagnostic request exists in the third rewriting information, then the diagnostic request is rewritten based on the third rewriting information.

[0114] The rewriting device parses the original diagnostic request and identifies all missing necessary slots, i.e., the information to be rewritten, such as the target vehicle, the Electronic Control Unit (ECU), and specific data items or parameters. Subsequently, the rewriting device checks whether the third rewriting information contains all the specific values ​​needed to fill these missing slots. If the third rewriting information covers all the information to be rewritten, the rewriting device determines that the rewriting conditions are complete and then uses the third rewriting information to rewrite or fill in the original diagnostic request, generating a final instruction that conforms to the syntax and can be directly delivered to downstream services, thereby avoiding execution failures or erroneous executions due to missing information.

[0115] S1813, if the information to be rewritten in the diagnostic request does not exist in the third rewriting information, then the diagnostic request is rewritten again using the second processing method.

[0116] Despite information fusion, if the third rewritten information still lacks certain key information to be rewritten—for example, the user has confirmed the vehicle, but the specific data items implicitly required in the original request are neither in the context nor provided by the user—the rewriting device cannot generate a complete instruction. In this case, the rewriting device does not guess or force a rewrite; instead, it determines that the rewriting attempt has failed and re-enters the clarification process. That is, the rewriting device processes the diagnostic request again using the second processing method. This includes regenerating clarification information based on the currently known partial information and the still missing slots, and asking the user follow-up questions again to ensure that the rewriting device will only output the final instruction after obtaining all the necessary information, thus guaranteeing the accuracy and executability of the instruction.

[0117] Accordingly, S182 includes sub-steps S1821 to S1823: S1821, if the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is write-type or fuzzy-type, determine whether all the information to be rewritten in the diagnostic request exists in the second rewrite information.

[0118] Because write operations (such as clearing fault codes and writing parameters) involve changes to the vehicle's state and are high-risk, the rewriting device adopts an extremely conservative strategy, relying solely on the second rewriting information explicitly provided by the user for judgment. The rewriting device rigorously verifies whether every piece of information to be rewritten (such as the target vehicle, target ECU, and specific values ​​to be written) required by the original diagnostic request is explicitly included in the second rewriting information provided by the user. In this case, any operation parameters not explicitly mentioned or confirmed by the user are considered missing and are not automatically supplemented based on historical context.

[0119] S1822, if all the information to be rewritten in the diagnostic request exists in the second rewriting information, then the diagnostic request is rewritten based on the second rewriting information.

[0120] Since the second rewritten information originates entirely from user confirmation or input, the rewriting device fills it into the corresponding slot of the original diagnostic request. In the generated rewritten instructions, every operation object and parameter has solid user confirmation as its basis, with no element of automatic deduction. For example, if the user explicitly replies "Confirm clearing engine control unit fault code P0171 for vehicle B," the rewriting device generates a standardized clearing instruction accordingly to prevent incorrect vehicle status changes due to misjudgment of the context.

[0121] S1823, if the information to be rewritten in the diagnostic request does not exist in the second rewriting information, then the diagnostic request is rewritten again using the second processing method.

[0122] If the second rewrite information provided by the user fails to cover all the information to be rewritten—for example, the user only confirms the vehicle but does not specify the exact parameter values ​​to be written—the rewrite device will refuse to generate an execution command and deem the confirmation invalid. Subsequently, the rewrite device will initiate a second processing method, namely, regenerating clarification information specifically addressing any missing mandatory fields not mentioned by the user. For example, prompting the user to "please enter the calibration parameter values ​​to be written," the rewrite device forces the user to provide all the critical parameters required for the write operation, thereby eliminating the risk of erroneous execution due to incomplete information.

[0123] For example, assuming the diagnostic request is "Check again" (read type), after clarification interaction, the rewriting device confirms that the vehicle verification data is consistent with the snapshot. The consistency information includes fault code P0300 (from the current interface), and the user's second rewritten information is confirmed as "Vehicle B". S1811 is executed, generating third rewritten information containing {Vehicle B, fault code P0300}. At this point, the original request's information to be rewritten is {Vehicle, fault code}, both of which are present in the third rewritten information. Therefore, S1812 can be executed, and the rewriting device generates "Query vehicle B's fault code P0300". If the user only replies "Vehicle B", while the original request actually implicitly requires querying two fault codes, but both the consistency information and the user's reply only provide one, then S1813 is executed, and the rewriting device again initiates a clarification inquiry to determine which specific fault code it is.

[0124] For a write-type example, the diagnostic request is "Write the matching value in," and the user's second rewrite information is "Write the throttle body matching for vehicle B." Executing S1821, the rewrite device checks the original request information to be rewritten {vehicle, component, matching value} and finds that the specific "matching value" is missing in the second rewrite information. Therefore, executing S1823, the rewrite device does not perform the rewrite but instead generates a clarification message: "Please enter the specific throttle body matching value." If the user replies with the complete value, then executing S1822 generates the write instruction.

[0125] By implementing different strategies for information fusion between read and write operations, a balance between security and efficiency is achieved. For read operations, the integration of consistency information and user responses maximizes the use of context, reduces user input, and improves interaction fluency. Integrity checks ensure no instructions are omitted. For write operations, strict limitation to using only explicitly provided second-level rewrite information, coupled with rigorous information completeness checks and re-clarification mechanisms, guarantees the security of subsequent instruction execution. This effectively avoids erroneous operations caused by mixed information sources, ensuring that every high-risk operation has complete and explicit user authorization, thus improving the safety and reliability of the vehicle diagnostic process.

[0126] It should be noted that each round of clarification information only addresses the most recent missing item, rather than listing all missing items at once, in order to avoid the coupling relationship between missing items leading to the generation of incorrect clarification information.

[0127] To prevent the rewriting device from getting stuck in an infinite loop of clarification dialogue when it cannot obtain complete information, in one optional way, S12 includes the following sub-step: S121, if the intent type of the diagnostic request is a read type, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten in a first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten in a second processing method within a first preset number of times.

[0128] When the intent type of the diagnostic request is determined to be read-type, the rewriting device first checks the verification conditions. If the verification conditions are met—that is, the multi-source information is consistent and complete—the rewriting device directly adopts the first processing method, i.e., the automatic rewriting method, using context information to complete the request and output it. If the verification conditions are not met, the rewriting device switches to the second processing method, i.e., initiating a clarification interaction. Unlike before, the rewriting device introduces a first preset number of interactions as an upper limit in this process. The first preset number of interactions refers to the maximum number of clarification interaction rounds allowed for read-type operations, which can be configured to, for example, 3 or 5 times. After each clarification attempt and receiving a user response, the rewriting device records the number of rounds already consumed. If the user response still does not complete all the missing information, the rewriting device will continue to initiate a new round of clarification based on the currently known information. However, as long as the number of rounds consumed has not reached the first preset number, the rewriting device will continue to try to guide the user to complete the information through a second processing method. This setting provides a relatively lenient opportunity for error correction and completion for low-risk read operations. Considering that read operations do not change the vehicle status, the rewriting device allows users to make multiple attempts to obtain the final query result, thereby improving the fault tolerance and user-friendliness of human-computer interaction.

[0129] Accordingly, S13 includes sub-step S132: if the intent type of the diagnostic request is write-type or fuzzy-type, the diagnostic request is rewritten in the second processing mode within a second preset number of times, wherein the first preset number of times is greater than the second preset number of times.

[0130] The rewriting device imposes stricter round limits on write-type or fuzzy-type diagnostic requests. When the intent type of a diagnostic request is determined to be write-type or fuzzy-type, due to its involvement in changes to vehicle status or potential high risk, the rewriting device forces the use of a second processing method, i.e., forced clarification. However, unlike read-type requests, the rewriting device sets a lower threshold for the number of interaction rounds for such operations, i.e., a second preset number. The second preset number refers to the maximum number of clarification interaction rounds allowed for high-risk operations, which can be configured to 1 or 2 times. The rewriting device strictly monitors the number of interaction rounds when initiating clarification. If the user fails to provide a complete and clear operation object after the first round of clarification, or if the response remains fuzzy in the second round of interaction, causing the rewriting device to be unable to generate a compliant write instruction, once the round count reaches the second preset number, the rewriting device will immediately terminate the clarification process and no longer allow rewriting through the second processing method. At this point, the rewriting device will determine that the current interaction cannot meet the safe execution conditions, refuse to generate any rewriting results, and output a prompt message requiring the user to re-enter a complete and clear instruction. This strict restriction is intended to prevent lengthy and ineffective back-and-forth dialogues in high-risk scenarios, and to avoid user fatigue due to repeated confirmations, which could lead to random clicks for confirmation and thus cause the risk of misoperation.

[0131] Because write operations are destructive, users need to accurately express their intentions within a few rounds; otherwise, the input is considered invalid, forcing the user to start over. This ensures that each write operation is performed when the user is conscious and clear. Read operations, on the other hand, are relatively safe. The device can invest more in interaction to help users clarify their intentions, uncovering the user's true needs through more rounds and providing better auxiliary query services.

[0132] By setting a tiered round limit mechanism, the rewriting device effectively controls the depth and duration of the interaction process. For high-risk write operations, strict round limits force users to provide precise instructions, avoiding safety hazards caused by distraction or fatigue due to prolonged interaction, thus establishing a safety-first principle. For low-risk read operations, relatively relaxed round limits reflect a service-first principle. Through multiple rounds of guidance, technicians can quickly locate the required data even when information is ambiguous, improving the usability and fault tolerance of the rewriting device. This differentiated interaction management strategy further optimizes the intelligence level and user experience of the automotive diagnostic assistant in actual workstation applications.

[0133] In addition, when the clarification of diagnostic requests for read-type applications reaches the maximum number of clarification interaction rounds, efforts can be made to rewrite or prompt for re-entry within the scope of confirmed information, with the specifics configured by the product strategy.

[0134] In automotive diagnostics, technicians may leave their workstations to handle other tasks after sending a request, or fail to respond for an extended period due to interruptions. Indefinitely waiting for a user's response not only consumes equipment resources, but more seriously, by the time the technician responds again after a long time, the vehicle's status may have changed—for example, the vehicle may have been driven away, the diagnostic interface may have been disconnected, or the work order may have been switched. Continuing to use the previously suspended clarified status for merging in this situation can easily lead to serious vehicle misoperation or erroneous command execution. Therefore, in one optional approach, the method further includes steps S183–S184: S183, a timer is enabled synchronously when clarification information is generated.

[0135] In this step, while executing the second processing method—generating and sending clarification information to the user—the rewriting device immediately starts a timing logic in the background. Specifically, the rewriting device uses the system clock to record the current time as the start time and loads a preset duration threshold as the preset time value. The preset time value refers to the maximum waiting time allowed for users to respond to clarification, configured according to the diagnostic service requirements, such as 60 seconds, 120 seconds, or 300 seconds. The timer starts running, monitoring the duration of the clarification suspension state in real time to prevent the clarification state from remaining indefinitely.

[0136] S184, if the second rewritten information corresponding to the clarification information is not obtained when the timer reaches the preset time value, a prompt message for re-entry is generated.

[0137] In this step, the rewriting device handles timeout invalidation. When the timer accumulates to a preset time value, a timeout event occurs. If the rewriting device has not received a valid response from the user regarding the clarification information through the input interface during this period (i.e., it has not obtained the second rewriting information), the rewriting device determines that the current clarification interaction has expired. At this time, the rewriting device will perform an invalidation operation, immediately clearing the suspended storage corresponding to the current session, releasing related memory resources, and discarding all previously temporarily stored context information (such as vehicle identity snapshots, original diagnostic requests, etc.). Subsequently, the rewriting device generates a re-entry prompt message, such as "Session timed out, please re-enter your command," and sends this prompt message back to the user. This means that the user's previous input has expired, and if the user has subsequent operational needs, a new and complete interaction process must be started again, thus avoiding the risk of context confusion and misoperation due to long delays.

[0138] Accordingly, S18 includes sub-step S185: if second rewritten information corresponding to the clarification information is obtained before the timer reaches a preset time value, then the diagnostic request is rewritten based on the second rewritten information.

[0139] When the rewriting device receives a user's response to the clarification information input, it first checks the current state of the timer. If the timer has not yet reached the preset time value, it means that the response was submitted within the valid clarification window. At this time, the rewriting device determines that the response is timely and valid, and agrees to continue processing. The rewriting device then extracts the second rewriting information from the user's response and continues to execute other sub-steps defined in step S18 (such as the aforementioned vehicle verification data comparison, integrity check, etc.), and finally rewrites the original diagnostic request based on the second rewriting information.

[0140] By setting timers and timeout invalidation, the rewriting device adds a time-dimensional safety guarantee to the diagnostic interaction process, thereby effectively managing system resources and preventing the accumulation of invalid pending states. In the ever-changing diagnostic workshop environment, vehicle and work order states may change at any time. The timeout mechanism ensures that the rewriting device only processes requests that are valid at the moment, forcing users to reconfirm their intentions after the object state may have changed, eliminating potential risks of misoperation caused by time differences.

[0141] In real-world automotive diagnostic scenarios, technicians often include multiple operational intentions in a single sentence, such as "first read the engine fault codes, then clear the transmission fault codes." If such complex requests containing multiple pieces of information to be modified are rewritten as a whole, it is often difficult to balance the safety levels and contextual requirements of different operations. Therefore, it is necessary to address complex diagnostic requests containing complex intentions or multiple operational objects. Figure 2 This illustration shows a flowchart of another diagnostic request rewriting method provided in an embodiment of this application. This method is still executed by the aforementioned rewriting device, as shown below. Figure 2 As shown, the method includes steps S21 to S24: S21, Obtain diagnostic request.

[0142] The device receives diagnostic requests from user input. These requests may be a single, simple instruction or a complex instruction containing multiple clauses that involve multiple different objects or types of actions.

[0143] The rewriting device first performs preliminary parsing and identification of the original text request to determine its structural complexity.

[0144] S22, If the diagnostic request contains multiple pieces of information to be rewritten, the diagnostic request is split into multiple diagnostic sub-requests based on the multiple pieces of information to be rewritten.

[0145] The rewriting device performs semantic analysis on the diagnostic request to identify the intended actions, the objects to be manipulated, and the logical relationships between them. If the rewriting device finds that the diagnostic request contains multiple pieces of information to be rewritten, such as involving different vehicle control units, different fault codes, or simultaneously containing two completely different action types, namely reading and writing, it determines that the request is a composite request.

[0146] To improve processing accuracy, the rewriting device breaks down the original diagnostic request into multiple relatively independent and logically clear diagnostic sub-requests based on the boundaries and logical connectors (such as then, and, after) of the information to be rewritten. Each diagnostic sub-request contains only one core action intent and the corresponding operation object.

[0147] For example, for the request "read the engine data of vehicle A and clear the fault code of vehicle B", the rewriting device breaks it down into sub-request one "read the engine data of vehicle A" and sub-request two "clear the fault code of vehicle B". By breaking it down, the originally complicated operations are transformed into independent sub-tasks.

[0148] S23. For any one of the multiple diagnostic sub-requests, if the intent type of the current diagnostic sub-request is read, then if the current diagnostic sub-request meets the verification conditions, the current diagnostic sub-request is rewritten in the first processing method; if the current diagnostic sub-request does not meet the verification conditions, the current diagnostic sub-request is rewritten in the second processing method.

[0149] For any sub-request whose intent type is determined to be read, the rewriting device performs verification according to the logic in the aforementioned embodiments. If the contextual information such as vehicles and components involved in the sub-request is consistent and complete across multiple information sources, thus satisfying the verification conditions, the rewriting device adopts the first processing method, which automatically completes the sub-request using the contextual information. If the sub-request has conflicting or missing information and does not meet the verification conditions, the rewriting device adopts the second processing method, which generates corresponding clarification information for the sub-request. This process ensures that even the read portion of a composite request must strictly adhere to security verification rules to prevent query errors caused by contextual confusion.

[0150] S24. For any one of the multiple diagnostic sub-requests, if the intent type of the current diagnostic sub-request is write or fuzzy, then the current diagnostic sub-request is rewritten using the second processing method.

[0151] For any sub-request whose intent type is determined to be either write-related (e.g., clear, write, label) or ambiguous (risk level difficult to determine, treated as write-related), the rewriting device will enforce the second processing method regardless of whether the information in the sub-request appears complete or which step in a composite request it is. This means that the rewriting device must generate clarification information for the sub-request, requiring the user to explicitly confirm the object and parameters of the write operation, thereby avoiding the potential risk of the user overlooking the operation risk due to excessively long instructions.

[0152] The diagnostic request is rewritten using the first processing method, including steps S24 to S25: S24, Read the first rewrite information based on the information to be rewritten in the current diagnostic sub-request.

[0153] The rewriting device analyzes the missing entity information (i.e., the information to be rewritten) for the currently processed read-type diagnostic sub-request. Then, it extracts the corresponding entity value from the verified multi-source consistency information as the first rewritten information. For example, for the sub-request "read engine speed," the information to be rewritten is "engine control unit identifier," and the first rewritten information is the specific identifier extracted from the context.

[0154] S25, rewrite the current diagnostic sub-request based on the first rewrite information.

[0155] The rewriting device fills the missing slots of the diagnostic sub-request with the extracted first rewriting information, generating a semantically complete and directly executable rewritten sub-request, which will then be output to the downstream service for execution.

[0156] The current diagnostic sub-request is rewritten using the second processing method, including steps S26 to S28: S26, Generate clarification information based on the information to be rewritten in the current diagnostic sub-request.

[0157] Based on the information to be modified in the current high-risk sub-request, the rewriting device generates targeted inquiry or confirmation messages. This clarification message aims to clearly show the user the upcoming write operation and its target, requiring the user to verify it.

[0158] S27, Obtain the second rewritten information corresponding to the clarification information.

[0159] The rewriting device receives the user's response to the clarification information and parses out the operation object confirmed by the user, namely the second rewriting information.

[0160] S28, rewrite the current diagnostic sub-request based on the second rewrite information.

[0161] The rewriting device uses the second rewriting information confirmed by the user to perform a final normalized rewriting of the current diagnostic sub-request, generating an execution instruction containing a clear operation target.

[0162] For example, if the diagnostic request received by the rewriting device is "Read the engine fault code first, then clear that fault code", steps S21 and S22 are executed first. The rewriting device recognizes that the request contains two actions and there are multiple pieces of information to be rewritten, so it breaks it down into two sub-requests: sub-request one "Read the engine fault code" (read type) and sub-request two "Clear that fault code" (write type). Next, sub-request one is processed. The rewriting device determines it to be a read type and checks the context. If the current vehicle context is consistent and contains fault code information, meeting the verification conditions, the first processing method is executed, automatically rewriting it to "Read the fault code of the current vehicle's engine control unit". Then, sub-request two is processed. The rewriting device determines it to be a write type and forces the second processing method. The rewriting device generates a clarification message "Please confirm whether to clear the fault code P0171 that was just read?". After the user replies "Confirm", the rewriting device generates the instruction "Clear the fault code P0171 of the current vehicle's engine control unit".

[0163] By breaking down complex diagnostic requests, the rewriting device can accurately process natural language instructions containing multiple operational steps, effectively avoiding the risk of distraction caused by the complexity of instructions and ensuring that each high-risk operation can be independently confirmed by the user. Simultaneously, it retains the automatic rewriting capability for read-type sub-requests when conditions are met, balancing the efficiency and security of complex instruction processing, and improving the reliability and user experience of the intelligent diagnostic assistant when handling real-world complex business scenarios.

[0164] This application embodiment obtains a diagnostic request. If the intent type of the diagnostic request is write-type or ambiguous, the diagnostic request is rewritten using a second processing method to classify and isolate high-risk operations involving changes in the state of vehicle components. Based on this, clarification information is generated based on the information to be rewritten in the diagnostic request, and second rewritten information corresponding to the clarification information is obtained. This forces the user to provide explicit confirmation of the operation object, making it impossible to rely solely on historical session information to automatically fill in execution parameters. This effectively solves the problem of vehicle-to-vehicle semantics in the prior art where blind rewriting leads to the misuse of vehicle A information for vehicle B operations, avoiding the loss of critical vehicle data, hardware damage, and safety accidents caused by object identification errors. Furthermore, if the intent type of the diagnostic request is read-type, the diagnostic request is rewritten using a first processing method when the diagnostic request meets the verification conditions. This allows for the automatic rewriting of low-risk read operations when the verification conditions are met, implementing differentiated processing strategies based on risk levels. This ensures both processing efficiency and the security of diagnostic request rewriting.

[0165] Figure 3 A schematic diagram of the structure of a diagnostic request rewriting device provided in an embodiment of this application is shown. Figure 3 As shown, the diagnostic request rewriting device 300 includes: an acquisition module 310, a first processing module 320, and a second processing module 330.

[0166] The acquisition module 310 is used to acquire diagnostic requests.

[0167] The first processing module 320 is configured to, if the intent type of the diagnostic request is a read type, rewrite the diagnostic request in a first processing method when the diagnostic request meets the verification conditions, and rewrite the diagnostic request in a second processing method when the diagnostic request does not meet the verification conditions. The first processing method for rewriting the diagnostic request includes reading first rewrite information based on the information to be rewritten in the diagnostic request, and rewriting the diagnostic request based on the first rewrite information. The second processing method for rewriting the diagnostic request includes generating clarification information based on the information to be rewritten in the diagnostic request, obtaining second rewrite information corresponding to the clarification information, and rewriting the diagnostic request based on the second rewrite information.

[0168] The second processing module 330 is used to rewrite the diagnostic request in a second processing method if the intent type of the diagnostic request is write-type or fuzzy-type.

[0169] The diagnostic request rewriting apparatus 300 provided in this application embodiment further includes a plurality of modules for performing each step of the diagnostic request rewriting method described above, which will not be described in detail here.

[0170] Figure 4 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the electronic device.

[0171] like Figure 4 As shown, the electronic device 400 may include a processor 402 and a memory 404.

[0172] The memory 404 is used to store the computer program 406. The memory 404 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk drive. The computer program 406 may include computer-executable instructions.

[0173] The processor 402 is used to execute the computer program 406 to implement the above-described method embodiment for rewriting the diagnostic request.

[0174] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Electronic device 400 may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0175] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for rewriting diagnostic requests.

[0176] This application provides a computer program that can be executed by a processor to implement the above-described method for rewriting diagnostic requests.

[0177] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for rewriting diagnostic requests.

[0178] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other electronic device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0179] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0180] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0181] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for rewriting a diagnostic request, characterized in that, The method includes: Request a diagnostic request; If the intent type of the diagnostic request is a read type, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten in a first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten in a second processing method. If the intent type of the diagnostic request is write-type or fuzzy-type, then the diagnostic request is rewritten using the second processing method; in, The rewriting of the diagnostic request using the first processing method includes: Read the first rewrite information based on the information to be rewritten in the diagnostic request; The diagnostic request is rewritten based on the first rewritten information; The rewriting of the diagnostic request using the second processing method includes: Clarification information is generated based on the information to be rewritten in the diagnostic request; Obtain the second rewritten information corresponding to the clarification information; The diagnostic request is rewritten based on the second rewritten information.

2. The method according to claim 1, characterized in that, If the intent type of the diagnostic request is a read class, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten using a first processing method; before the diagnostic request is rewritten using a second processing method when the diagnostic request does not meet the verification conditions, after obtaining the diagnostic request, the method further includes: Read multiple information sources, wherein the multiple information sources include at least any two of the following: the vehicle identifier bound to the session corresponding to the diagnostic request, the vehicle identifier read through the diagnostic interface connected to the target vehicle, the historical session data of the session corresponding to the diagnostic request, the page data to which the session corresponding to the diagnostic request is currently redirected, the function identifier of the function currently being executed by the session corresponding to the diagnostic request, and the diagnostic process data being executed by the session corresponding to the diagnostic request. The information from the multiple information sources is compared to obtain the comparison results; If the comparison results indicate that the information from the multiple information sources is consistent, and the information to be rewritten in the diagnostic request exists in all of the multiple information sources, then the diagnostic request is determined to meet the verification conditions. If the comparison result indicates that there is an inconsistency between the information from the multiple information sources, or if the information to be rewritten in the diagnostic request does not exist in the multiple information sources, then it is determined that the diagnostic request does not meet the verification condition.

3. The method according to claim 2, characterized in that, If the comparison result indicates inconsistencies between the information from the multiple information sources, or if the information to be rewritten in the diagnostic request does not exist in the multiple information sources, then determining that the diagnostic request does not meet the verification condition includes: If the comparison result indicates that there is an inconsistency between the information from the multiple information sources, then it is determined that the diagnostic request does not meet the verification condition, and the clarification type of the diagnostic request is determined to be the conflict option clarification type. If the information to be rewritten in the diagnostic request does not exist in the multi-channel information source, then it is determined that the diagnostic request does not meet the verification condition, and the clarification type of the diagnostic request is determined to be the missing required slot type. If the intent type of the diagnostic request is write-type or fuzzy-type, then the diagnostic request is rewritten using the second processing method, including: If the intent type of the diagnostic request is write or ambiguous, then the clarification type of the diagnostic request is determined to be write object confirmation type, and the diagnostic request is rewritten using the second processing method. The generation of clarification information based on the information to be rewritten in the diagnostic request includes: Clarification information is generated based on the information to be rewritten and the clarification type in the diagnostic request.

4. The method according to claim 2, characterized in that, If the intent type of the diagnostic request is a read class, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten using a first processing method; before the diagnostic request is rewritten using a second processing method when the diagnostic request does not meet the verification conditions, after obtaining the diagnostic request, the method further includes: The intent type of the diagnostic request is determined based on a preset rule vocabulary; And / or, The intent type of the diagnostic request is determined based on a preset model.

5. The method according to claim 2, characterized in that, After reading the multiple information sources, the method further includes: Consistent information from the multiple information sources is identified as consistent information. After generating clarification information based on the information to be rewritten in the diagnostic request, and before obtaining the second rewritten information corresponding to the clarification information, the method further includes: Obtain vehicle snapshot data at the current moment; After obtaining the second rewritten information corresponding to the clarification information, and before rewriting the diagnostic request based on the second rewritten information, the method further includes: Obtain the vehicle verification data at the current moment; The step of rewriting the diagnostic request based on the second rewritten information includes: If the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read, a third rewrite information is generated based on the consistency information and the second rewrite information, and the diagnostic request is rewritten based on the third rewrite information. If the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is write-type or fuzzy-type, the diagnostic request is rewritten based on the second rewrite information.

6. The method according to claim 5, characterized in that, If the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read, third rewriting information is generated based on the consistency information and the second rewriting information, and the diagnostic request is rewritten based on the third rewriting information, including: If the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is read, third rewrite information is generated based on the consistency information and the second rewrite information. If all the information to be rewritten in the diagnostic request exists in the third rewriting information, then the diagnostic request is rewritten based on the third rewriting information; If the information to be rewritten in the diagnostic request does not exist in the third rewriting information, then the diagnostic request is rewritten again using the second processing method; If the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is write-type or fuzzy-type, the diagnostic request is rewritten based on the second rewrite information, including: If the vehicle verification data is consistent with the vehicle snapshot data, then when the intent type of the diagnostic request is write-type or fuzzy-type, it is determined whether all the information to be rewritten in the diagnostic request exists in the second rewriting information. If all the information to be rewritten in the diagnostic request exists in the second rewriting information, then the diagnostic request is rewritten based on the second rewriting information; If the information to be rewritten in the diagnostic request does not exist in the second rewrite information, then the diagnostic request is rewritten again using the second processing method.

7. The method according to claim 6, characterized in that, If the intent type of the diagnostic request is a read class, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten using a first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten using a second processing method, including: If the intent type of the diagnostic request is a read type, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten in the first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten in the second processing method within a first preset number of times. If the intent type of the diagnostic request is write-type or fuzzy-type, then the diagnostic request is rewritten using the second processing method, including: If the intent type of the diagnostic request is write-type or fuzzy-type, the diagnostic request is rewritten in the second processing method within a second preset number of times; The first preset number of times is greater than the second preset number of times.

8. The method according to claim 1, characterized in that, The method further includes: Start the timer synchronously when generating clarification information; If the second rewritten information corresponding to the clarification information is not obtained when the timer reaches the preset time value, a prompt message for re-entry is generated. The step of rewriting the diagnostic request based on the second rewritten information includes: If second rewritten information corresponding to the clarification information is obtained before the timer reaches a preset time value, the diagnostic request is rewritten based on the second rewritten information.

9. The method according to claim 1, characterized in that, After obtaining the diagnostic request, the method further includes: If the diagnostic request contains multiple pieces of information to be rewritten, then the diagnostic request is split into multiple diagnostic sub-requests based on the multiple pieces of information to be rewritten. If the intent type of the diagnostic request is a read class, then when the diagnostic request meets the verification conditions, the diagnostic request is rewritten using a first processing method; when the diagnostic request does not meet the verification conditions, the diagnostic request is rewritten using a second processing method, including: For any one of the plurality of diagnostic sub-requests, if the intent type of the current diagnostic sub-request is a read class, then when the current diagnostic sub-request meets the verification conditions, the current diagnostic sub-request is rewritten in a first processing method; when the current diagnostic sub-request does not meet the verification conditions, the current diagnostic sub-request is rewritten in a second processing method. If the intent type of the diagnostic request is write-type or fuzzy-type, then the diagnostic request is rewritten using the second processing method, including: For any of the plurality of diagnostic sub-requests, if the intent type of the current diagnostic sub-request is write or fuzzy, then the current diagnostic sub-request is rewritten using the second processing method. in, The rewriting of the current diagnostic sub-request using the first processing method includes: Read the first rewrite information based on the information to be rewritten in the current diagnostic sub-request; The current diagnostic sub-request is rewritten based on the first rewritten information; The rewriting of the current diagnostic sub-request using the second processing method includes: Clarification information is generated based on the information to be rewritten in the current diagnostic sub-request; Obtain the second rewritten information corresponding to the clarification information; The current diagnostic sub-request is rewritten based on the second rewriting information.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method for rewriting a diagnostic request as described in any one of claims 1 to 9.

Images