Vehicle diagnosis workflow assurance method, device and equipment based on formal verification

Abstract

The application provides a vehicle diagnosis workflow guarantee method, device and equipment based on formal verification, and belongs to the technical field of vehicle diagnosis. The method comprises the following steps: obtaining a diagnosis workflow containing a plurality of diagnosis operation instructions, analyzing the diagnosis workflow into a state machine model, wherein each diagnosis operation instruction is modeled as a state transition containing a precondition, an action and a postcondition; obtaining a safety specification, converting the safety specification into a temporal logic formula, verifying whether the state machine model satisfies the temporal logic formula by using a formal verification engine, and obtaining a verification result; and processing the diagnosis workflow based on the verification result. The application is beneficial to improving the efficiency and accuracy of compliance verification of the diagnosis workflow.

Description

Technical Field

[0001] This invention relates to the field of vehicle diagnostics technology, and specifically to a method, apparatus, and equipment for ensuring vehicle diagnostic workflow based on formal verification. Background Technology

[0002] The SOVD (Service-Oriented Vehicle Diagnostics) protocol provides a standardized RESTful API interface for vehicle diagnostics. Diagnostic tools can execute routines that include firmware upgrades, parameter calibration, and actuator activation by calling the SOVD API. To further improve diagnostic efficiency, some advanced diagnostic tools support orchestrating multiple SOVD API calls into diagnostic workflows, such as a serialized execution flow of "reading fault codes, executing a specific routine, and reading fault codes again." To ensure the security and compliance of such workflow execution, existing SOVDServers primarily employ a role-based access control (RBAC) mechanism to manage client permissions for calling routines.

[0003] In the process of developing this invention, the inventors discovered that existing methods have at least the following drawbacks. First, compliance verification of the diagnostic workflow relies on manual review and bench testing. The SOVD call sequence arranged by diagnostic engineers may violate vehicle operation safety regulations. For example, the high-voltage power-down routine may not be called before performing an ECU firmware upgrade, or a transmission parameter writing operation may be performed while the vehicle is in motion. Manual review is insufficient to exhaust all possible violation paths, resulting in low efficiency and easy omissions. Second, the SOVD service discovery mechanism can only provide the routine name, description, and parameter list, and cannot express the routine's preconditions (such as the vehicle speed must be 0) and side effects (such as resetting adaptive learning values). When the client calls a routine, it cannot automatically verify whether the current vehicle state meets the execution conditions, and the implicit state dependencies between multiple routines cannot be automatically deduced. In addition, when safety auditors check the SOVD operation logs afterward, they can only know who called which routine, but cannot automatically determine whether the call was compliant under the vehicle state at that time.

[0004] Therefore, how to automate the compliance verification of diagnostic workflows, enabling vehicle operation safety standards to be formalized and automatically checked, and automatically locating problem nodes and guiding repairs when violations are detected, thereby reducing reliance on manual review and bench testing and improving the security and efficiency of diagnostic workflow deployment, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] In view of this, it is necessary to provide a method, device and electronic device for ensuring vehicle diagnostic workflow based on formal verification, so as to solve the technical problems of low efficiency and low security of workflow compliance verification caused by the unpredictable calling conditions of existing diagnostic routines and the difficulty in automating the auditing of operation logs.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a vehicle diagnostic workflow assurance method based on formal verification, comprising: Obtain the diagnostic workflow, which contains multiple diagnostic operation instructions; The diagnostic workflow is parsed as a state machine model, wherein each diagnostic operation instruction is modeled as a state transition, and the state transition includes a precondition, an action, and a postcondition. Obtain the security specifications, convert the security specifications into temporal logic formulas, and use a formal verification engine to verify whether the state machine model satisfies the temporal logic formulas, and obtain the verification results; Based on the verification results, diagnostic processing is performed on the diagnostic workflow.

[0007] In one possible implementation, the state machine model consists of multiple state nodes and state transitions connecting the state nodes. The state machine model includes state variables and the values ​​of the state variables at each state node. The state variables include at least one of vehicle speed, gear position, high voltage power-on state, safety unlock state, engine speed, and battery state of charge.

[0008] In one possible implementation, the security specification is converted into a timing logic formula, including: Obtain a structured rule description file, wherein the structured rule description file contains at least one rule, and each rule contains a rule type identifier and a rule condition expression; The type of the rule is determined based on the rule type identifier, and the type includes security constraint type, precondition constraint type, sequence constraint type, and response constraint type. Based on the rule type identifier and the rule condition expression, the rule is mapped to a corresponding type of time-series logic formula.

[0009] In one possible implementation, the rule is mapped to a corresponding type of time-series logic formula, including: The rules of the security constraint type are converted into a first type of temporal logic formula, which indicates that the first condition and the second condition are not both true at the same time. The rules of the pre-constraint type are converted into a second type of temporal logic formula, which means that the target pre-conditions must be met before the target diagnostic operation instruction is executed. The rules of the sequential constraint type are converted into a third type of temporal logic formula, which indicates that the first diagnostic operation instruction must be executed before the second diagnostic operation instruction is executed. The rules of the response constraint type are converted into a fourth type of time-series logic formula, which means that the response condition must be met within a preset time range after the trigger condition is met.

[0010] In one possible implementation, based on the verification result, diagnostic processing is performed on the diagnostic workflow, including: When the verification result is satisfactory, a verification pass indication is output; When the verification result is not satisfied, the counterexample path output by the formal verification engine is obtained, and violation explanation information is generated based on the counterexample path; Based on the violation explanation information, a correction operation is performed on the diagnostic workflow to obtain a corrected workflow, and incremental verification is performed on the corrected workflow. When the incremental verification passes, a verification pass indication is output, and the corrected workflow is deployed to the vehicle diagnostic execution terminal.

[0011] In one possible implementation, generating violation explanation information based on the counterexample path includes: Extract the state variable values ​​and workflow step identifiers corresponding to each state node from the counterexample path; Traverse the state nodes in the counterexample path and mark the violation step at the first state transition that violates the timing logic formula; Extract the preconditions, actual state variable values, and required state variable values ​​corresponding to the violation steps; The step identifier of the violation step, the rule identifier of the violation, the actual state variable value, and the required state variable value are filled into the preset explanation template to generate violation explanation information.

[0012] In one possible implementation, performing a corrective operation on the diagnostic workflow based on the violation explanation information includes: The type of root cause of the violation is determined based on the violation explanation information; Based on the type of violation root cause, a corresponding correction template is matched from the correction template library, which contains at least one of the following correction templates: Insert a pre-check template to insert conditional check and diagnostic operation instructions before the violation step; Add a pre-routine template to insert a pre-routine call instruction before the violation step; Adjust the sequence template to swap the execution order of adjacent diagnostic operation instructions that violate dependencies; Add a status wait template to insert diagnostic operation instructions that loop through the status variable until the condition is met. The diagnostic workflow is corrected based on the matched correction template to obtain the corrected workflow.

[0013] In one possible implementation, incremental verification is performed on the revised workflow, including: Determine the location of the modification node corresponding to the correction operation in the diagnostic workflow; Based on the modified node position, the affected state subspace is determined from the state machine model, the affected state subspace containing state nodes from the modified node position to the endpoint of the diagnostic workflow; Using the previous state before the modified node position as the initial state, the affected state subspace is verified.

[0014] On the other hand, the present invention also provides a vehicle diagnostic workflow assurance device based on formal verification, comprising: The instruction acquisition module is used to acquire the diagnostic workflow, which contains multiple diagnostic operation instructions. The instruction parsing module is used to parse the diagnostic workflow into a state machine model, wherein each diagnostic operation instruction is modeled as a state transition, and the state transition includes a precondition, an action, and a postcondition. The specification transformation module is used to obtain the security specification, convert the security specification into a temporal logic formula, and use a formal verification engine to verify whether the state machine model satisfies the temporal logic formula, thereby obtaining the verification result. The verification processing module is used to perform diagnostic processing on the diagnostic workflow based on the verification results.

[0015] Thirdly, the present invention also provides an electronic device, including a communication interface, a memory, and a processor; The communication interface is used to obtain diagnostic workflows and safety specifications; The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the formal verification-based vehicle diagnostic workflow assurance method described in any of the above implementations.

[0016] The beneficial effects of this invention are as follows: The vehicle diagnostic workflow assurance method based on formal verification provided by this invention parses the diagnostic workflow into a state machine model and explicitly models the preconditions, actions, and postconditions of each diagnostic operation instruction. This formally expresses the vehicle state constraints and state change results on which routine calls depend, solving the problem of unpredictable routine call conditions. By converting safety specifications into temporal logic formulas and using a formal verification engine to automatically verify whether the state machine model satisfies the temporal logic formulas, this method replaces manual review with automation, avoiding omissions caused by manually checking safety specifications line by line, and improving the efficiency and coverage of compliance verification. Based on the verification results, the diagnostic workflow is processed so that when the verification is not satisfied, a correction operation can be triggered on the workflow, realizing the linkage between verification and correction. This reduces the reliance on manual intervention and repeated bench testing, improving the security of diagnostic workflow deployment and the efficiency of development iteration. Attached Figure Description

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

[0018] Figure 1 A schematic flowchart of an embodiment of the vehicle diagnostic workflow assurance method based on formal verification provided by the present invention; Figure 2 For the present invention Figure 1 A schematic diagram of an embodiment of S103; Figure 3 For the present invention Figure 1 A schematic diagram of an embodiment of S104; Figure 4 For the present invention Figure 3 A schematic diagram of an embodiment of S302; Figure 5 For the present invention Figure 3 A schematic diagram of an embodiment of S303; Figure 6 For the present invention Figure 3 A flowchart illustrating another embodiment of S303; Figure 7 A schematic diagram of the formal verification engine for the formal verification-based vehicle diagnostic workflow assurance method provided by the present invention. Figure 8 A schematic diagram of an embodiment of the vehicle diagnostic workflow assurance device based on formal verification provided by the present invention; Figure 9 A schematic diagram of an embodiment of the electronic device provided by the present invention. Detailed Implementation

[0019] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0020] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] This invention provides a method, apparatus, and electronic device for ensuring vehicle diagnostic workflow based on formal verification. The technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0023] Figure 1 This is a schematic flowchart of an embodiment of the vehicle diagnostic workflow assurance method based on formal verification provided by the present invention, as shown below. Figure 1 As shown, the vehicle diagnostic workflow assurance method based on formal verification includes: S101. Obtain the diagnostic workflow, which contains multiple diagnostic operation instructions.

[0024] A diagnostic workflow is a serialized diagnostic task composed of multiple SOVD API calls arranged in a specific execution order. The SOVD protocol supports diagnostic tool execution routines, which may include operations such as writing configurations to vehicle ECUs, firmware upgrades, parameter calibration, and actuator activation. In specific implementations, the diagnostic workflow can be described and stored in YAML or JSON format.

[0025] S102. Parse the diagnostic workflow into a state machine model, where each diagnostic operation instruction is modeled as a state transition, and the state transition includes preconditions, actions, and postconditions.

[0026] A state machine model is a mathematical model used to describe the dynamic behavior of a system. It defines the system's behavior as a set of allowed states and the transition relationships between these states.

[0027] In this optional embodiment, the state machine model can be represented as M=(S, S0, T, AP, L), where S is the state space, S0 is the initial state, T is the transition relation, AP is the set of atomic propositions, and L is the label function. This representation provides a standard mathematical input model for subsequent formal verification.

[0028] The diagnostic workflow, parsed as a state machine model, serves as the input model for formal verification. The state machine model consists of multiple state nodes and state transitions connecting these nodes. Each SOVD API call is modeled as a state transition, including preconditions, actions, and postconditions.

[0029] It should be noted that the precondition refers to the state condition that must be met before calling the diagnostic operation instruction, such as the vehicle speed must be 0; the action is used to indicate the change in the state variable after the operation is performed, such as setting the high voltage power-on state to OFF; the postcondition refers to the state condition that is guaranteed to be true after the call.

[0030] Furthermore, in some embodiments of the present invention, the state machine model consists of multiple state nodes and state transitions connecting the state nodes, and the state machine model includes state variables and the values ​​of the state variables at each state node.

[0031] Specifically, state variables include, but are not limited to, the following types: vehicle speed, gear position, high-voltage power-on status, security unlock status, engine speed, battery state of charge, current session ID, and list of executed routines. These state variables are used to describe the complete state of the vehicle at various moments during the execution of the diagnostic workflow.

[0032] S103. Obtain the security specifications, convert the security specifications into temporal logic formulas, and use a formal verification engine to verify whether the state machine model satisfies the temporal logic formulas, and obtain the verification results.

[0033] Vehicle operation safety specifications are typically described in natural language. This step converts these informal safety specifications into temporal logic formulas that can be automatically checked by a formal verification engine.

[0034] Specifically, temporal logic includes different branches such as Linear Temporal Logic (LTL) and Computation Tree Logic (CTL). Linear Temporal Logic treats the system execution path as a linear sequence of states, on which formulas are evaluated.

[0035] The basic operators of linear temporal logic include: □ (always, indicating that the formula is true in the current and all future states), ◇ (finally, indicating that the formula is true in the present or some future state), ○ (next, indicating that the formula is true in the next state), and U (until, indicating that the formula is true until another formula is true).

[0036] Among them, computation tree logic can quantify the branch structure of the system execution path and express two types of properties: existence (there exists an execution path that satisfies this) and universality (all execution paths satisfy this).

[0037] It should be noted that sequential logic is a formal description language with strict syntactic and semantic definitions. Compared with natural language descriptions, it is unambiguous and therefore suitable as an input specification language for formal verification.

[0038] As a preferred approach, this embodiment uses linear temporal logic formulas as the target expression form of the safety specification.

[0039] In this embodiment, the safety specification is described in natural language, such as "high voltage must not be disconnected while driving." Through a rule compiler, this natural language rule is converted into a corresponding temporal logic formula: □ ¬(vehicle_speed>0 ∧high_voltage == OFF). This formula mathematically precisely expresses the safety constraint that "driving state and high voltage disconnection state cannot be true simultaneously at any time." The formal verification engine receives this temporal logic formula as a verification attribute and inputs it along with the state machine model into the model detector, automatically determining whether all execution paths of the state machine model satisfy the formula.

[0040] Formal verification first abstracts the system to be verified into a formal model, describes the properties the system should satisfy as formal specifications, and then automatically determines whether the model satisfies these specifications using mathematical methods. Formal verification mainly includes two methods: model checking and theorem proving. Model checking, based on model theory, determines whether the model satisfies the properties by exhaustively searching the system's state space.

[0041] As a preferred approach, the formal verification engine in this embodiment is implemented using a model detector. The model detector receives a state machine model and temporal logic formulas as input, and automatically checks whether the state machine model satisfies all temporal logic formulas. The model detector traverses the state space of the state machine model and checks whether each execution path satisfies the temporal logic formulas.

[0042] Alternatively, the model detector can be implemented using open-source tools such as NuSMV or Spot.

[0043] For state spaces containing continuous variables, such as vehicle speed which is a continuously changing value, predicate abstraction can be used to discretize the continuous domain into finite intervals. For large-scale state spaces, partial order reduction or symbolic model detection can be used, and techniques based on BDD or SAT can be employed to mitigate the state explosion problem.

[0044] S104. Based on the verification results, process the diagnostic workflow.

[0045] When the verification result is satisfactory, it indicates that the diagnostic workflow meets all compliance rules in all reachable states, and the verification passes. When the verification result is unsatisfactory, it indicates that there is at least one execution path from the initial state to the non-compliant state, and this path needs to be addressed.

[0046] This embodiment parses the diagnostic workflow into a state machine model and explicitly models the preconditions, actions, and postconditions for each diagnostic operation instruction, thus formally expressing the vehicle state constraints and state change results upon which routine calls depend. By converting safety specifications into temporal logic formulas and automatically verifying whether the state machine model satisfies these formulas using a formal verification engine, automation replaces manual review, avoiding oversights caused by manually checking safety specifications line by line, and improving the efficiency and completeness of compliance verification. The diagnostic workflow is processed based on the verification results, triggering corrective operations when verification fails, achieving linkage between verification and correction. This reduces reliance on manual intervention and repeated bench testing, improving the security of diagnostic workflow deployment and the efficiency of development iterations.

[0047] In some embodiments of the present invention, such as Figure 2 As shown, step S103 converts the safety specification into a timing logic formula, which specifically includes the following sub-steps: S201. Obtain the structured rule description file. The structured rule description file contains at least one rule, and each rule contains a rule type identifier and a rule condition expression.

[0048] The structured rule description file can be written in YAML format, with each rule bound to a unique ID, creation date, and source requirement number, supporting rule version management and traceability.

[0049] S202. Determine the type of the rule based on the rule type identifier. The types include security constraint type, precondition constraint type, sequence constraint type, and response constraint type.

[0050] S203. Based on the rule type identifier and the rule condition expression, map the rule to the corresponding type of time-series logic formula.

[0051] In some embodiments of the present invention, step S203 maps the rules to corresponding time-series logic formulas, specifically including the following mapping methods: Rules of the safety constraint type are converted into first-class sequential logic formulas, which indicate that the first condition and the second condition do not both hold.

[0052] For example, the rule "high voltage must not be disconnected while driving" is converted into a timing logic formula □ ¬(vehicle_speed>0∧ high_voltage == OFF), indicating that the driving state and the high voltage disconnection state do not hold simultaneously.

[0053] The rules of the precondition type are converted into the second type of timing logic formula, which means that the target preconditions must be met before the target diagnostic operation instruction is executed.

[0054] For example, the rule "vehicle speed must be 0 before firmware upgrade" is converted into the timing logic formula □(call_firmware_upgrade → ◇(vehicle_speed == 0)), which means that the vehicle speed must be 0 before the firmware upgrade operation is performed.

[0055] The rules of the sequential constraint type are converted into the third type of sequential logic formula, which means that the first diagnostic operation instruction must be executed before the second diagnostic operation instruction is executed.

[0056] For example, the rule "the calibration must be unlocked before writing" is converted into the timing logic formula □(call_calibration_write → ◇(call_unlock)), which means that the unlock operation must be performed before the calibration write operation is performed.

[0057] The rules of the response constraint type are converted into the fourth type of timing logic formula, which means that the response condition must be met within a preset time range after the trigger condition is met.

[0058] For example, the rule "motor controller is ready within 100ms after high voltage is applied" is converted into the timing logic formula □(high_voltage == ON → ◇[0, 100ms] motor_controller_ready), which means that the motor controller is ready condition must be met within 100ms after the high voltage is applied.

[0059] This embodiment converts safety specifications described in natural language into temporal logic formulas with strict mathematical semantics, enabling the formal verification engine to automatically identify and check safety constraints. This eliminates human interpretation bias caused by ambiguity in natural language understanding and avoids oversights resulting from manual verification of safety specifications. Furthermore, by establishing corresponding temporal logic formula mapping methods for four types of rules—safety constraints, preconditions, sequence constraints, and response constraints—various vehicle operation safety specifications can be accurately expressed and automatically verified. This improves the verifiability of safety specifications and the accuracy of compliance verification in diagnostic workflows, helping to reduce safety risks caused by misunderstandings of specifications or omissions in manual review.

[0060] In some embodiments of the present invention, such as Figure 3 As shown, step S104 processes the diagnostic workflow based on the verification results, specifically including the following sub-steps: S301. When the verification result is satisfactory, output a verification pass indication.

[0061] S302. When the verification result is not satisfied, obtain the counterexample path output by the formal verification engine and generate violation explanation information based on the counterexample path.

[0062] The counterexample path is the specific execution path from the initial state to the violation state, in the format S0→S1→S2→…→S n The state sequence. This path is automatically output by the model detector when a violation is detected.

[0063] S303. Based on the violation explanation information, perform a correction operation on the diagnostic workflow to obtain the corrected workflow, and perform incremental verification on the corrected workflow.

[0064] Corrective actions aim to eliminate the root causes of violations. Common root cause types include missing pre-check nodes, incorrect node order, state variables not being updated at the correct time, and incorrect input parameters. Incremental validation only re-validates the affected state subspace, rather than validating the entire model from scratch, significantly improving validation efficiency.

[0065] S304. When incremental verification passes, output a verification pass indication and deploy the corrected workflow to the vehicle diagnostic execution end.

[0066] If incremental verification fails, the process reverts to the original workflow, records the failure information, and generates a detailed report for manual intervention.

[0067] It should be understood that S301 to S304 are not strictly executed in sequence. S301 and S302 are actually two mutually exclusive conditional branches, corresponding to the two verification results of verification pass and verification fail, respectively. These two branches are executed one at a time, and there is no temporal order between them. S303 and S304 are sub-steps executed sequentially within the S302 branch, used to complete the entire processing flow from non-compliance to correction and then to verification pass.

[0068] Through the above approach, this embodiment directly outputs a pass indication when verification passes and automatically enters a correction loop when verification fails. This achieves differentiated processing driven by verification results, avoiding the security risks associated with directly deploying workflows that fail verification to the vehicle execution end. Furthermore, the correction process employs an incremental verification method, re-verifying only the state subspace from the modification node to the workflow endpoint, rather than performing a full re-verification of the entire state machine model. This reduces computational overhead while ensuring verification accuracy, thus improving the overall processing efficiency of compliance verification and correction for diagnostic workflows.

[0069] In some embodiments of the present invention, such as Figure 4 As shown, step S302 generates violation explanation information based on the counterexample path, specifically including the following steps: S401. Extract the state variable values ​​and workflow step identifiers corresponding to each state node from the counterexample path.

[0070] S402. Traverse the state nodes in the counterexample path and mark the violation step at the first state transition that violates the sequential logic formula.

[0071] S403. Extract the preconditions, actual state variable values, and required state variable values ​​corresponding to the violation steps.

[0072] S404. Fill in the step identifier of the violation step, the rule identifier of the violation, the actual state variable value, and the required state variable value into the preset explanation template to generate violation explanation information.

[0073] The counterexample path is the specific execution path from the initial state to the violation state, and its format is S0→S1→S2→…→S n The state sequence is automatically output by the model detector when a violation is detected. Each state node in the negative example path is associated with a corresponding diagnostic operation instruction and the value of the state variable in that state.

[0074] After obtaining the negative example path, the first step is to extract the state variable values ​​corresponding to each state node and the step identifier of each node in the workflow to clarify the position of each state node in the entire diagnostic workflow. Secondly, the process traverses the negative example path node by node, starting from the initial state, and marks the first state transition that violates the sequential logic formula as a violation step. The reason for choosing the first violation point is that it is the starting trigger point of the entire violation path, and locating this point is crucial for subsequent corrections.

[0075] Then, the preconditions corresponding to the violation step, the actual state variable values ​​before the execution of the step, and the state variable values ​​required for verification are extracted. The preconditions are recorded in the state transition definition corresponding to the diagnostic operation instruction, the actual state variable values ​​are taken from the state record of the state node preceding the violation step in the counterexample path, and the state variable values ​​required for verification are parsed from the violated sequential logic formula.

[0076] Finally, the step identifier of the violation, the rule identifier of the violation, the actual state variable value, and the required state variable value are filled into the preset explanation template to generate violation explanation information.

[0077] The preset explanation template is a predefined structured text template used to convert the mathematical state information in the counterexample path into a description that conforms to the expression habits of natural language. The template reserves placeholders for step identifiers, rule identifiers, actual state values, and required state values. After filling in the corresponding information, complete violation explanation information can be generated.

[0078] As an example, if the vehicle speed is 35km / h when executing the firmware upgrade routine in step 3, violating the rule that "the vehicle speed must be 0 before firmware upgrade", the violation explanation information can be described as: "When executing the firmware upgrade routine in step 3, rule R-012 is violated, which requires the prerequisite that the vehicle speed is equal to 0. The actual state is a vehicle speed of 35km / h. It is recommended to insert a vehicle speed check node after step 2."

[0079] The violation explanation information can be encapsulated in JSON format and returned to the diagnostic tool via the SOVD extended API. The generated explanation information includes the violation node ID, violation rule number, and remediation suggestions, enabling engineers to quickly locate the problem without having to manually analyze the mathematical state sequence in the counterexample path.

[0080] In this way, the abstract counterexample paths output by the model detector are transformed into natural language violation explanations that engineers can directly understand. This eliminates the understanding barrier between formal verification results and diagnostic engineers, reduces the time cost required for manual analysis of counterexample paths, and helps improve the efficiency of compliance issue investigation and location.

[0081] In some embodiments of the present invention, such as Figure 5 As shown, step S303 involves performing a correction operation on the diagnostic workflow based on the violation explanation information, specifically including the following sub-steps: S501. Determine the type of root cause of the violation based on the violation explanation information.

[0082] S502. Based on the type of root cause of the violation, match the corresponding correction template from the correction template library.

[0083] The correction template library contains at least one of the following correction templates: Insert a pre-check template to insert conditional check and diagnostic operation instructions before the violation step. For example, if the violation is caused by a vehicle speed that is not zero during a firmware upgrade, this template inserts an API call to read the vehicle speed before the firmware upgrade step.

[0084] Add a pre-routine template to insert a pre-routine call instruction before the violation step. For example, if the violation is caused by performing a calibration write without executing the unlock routine, this template inserts an unlock routine call before the calibration write step.

[0085] Adjust the order template to swap the execution order of adjacent diagnostic operation instructions that violate dependencies.

[0086] Add a status wait template to insert diagnostic operation instructions that loop through the status variable until a condition is met.

[0087] S503. Perform a correction operation on the diagnostic workflow based on the matched correction template to obtain the corrected workflow.

[0088] In this embodiment, the type of root cause of a violation is determined based on the violation explanation information, and then a corresponding correction template is matched from the correction template library to perform the correction operation. The correction template library contains four types of templates: inserting pre-checks, adding pre-routines, adjusting the execution order, and adding status waits, each corresponding to a different type of root cause of a violation. Different root causes of violations are handled using different correction templates. When pre-conditions are not met, corresponding checks or wait operations are inserted; when dependencies are violated, the execution order is adjusted or missing pre-routines are added, ensuring that the correction action accurately targets the specific root cause of the violation step. Furthermore, the correction template library can be expanded and updated according to actual diagnostic scenarios, and newly added templates can be automatically identified and called by subsequent matching processes.

[0089] Based on this, the execution of the correction operation and the subsequent incremental verification form a closed-loop process from violation identification to correction and then to verification. This eliminates the need for repeated manual modifications and submissions for verification, which helps reduce the number of manual interventions and the development and iteration cycle of the diagnostic workflow.

[0090] In some embodiments of the present invention, such as Figure 6As shown, step S303 performs incremental verification on the revised workflow, which specifically includes the following sub-steps: S601. Determine the location of the modification node corresponding to the correction operation in the diagnostic workflow.

[0091] S602. Based on the location of the modified node, determine the affected state subspace from the state machine model. The affected state subspace contains state nodes from the location of the modified node to the end point of the diagnostic workflow.

[0092] S603. Using the previous state before the node position was modified as the initial state, verify the affected state subspace.

[0093] In incremental verification, the repair only involves the portion of the workflow that begins with the modified node; the previous state space remains unchanged, so only the affected portion needs to be re-verified. This approach significantly improves verification efficiency in large-scale workflows.

[0094] It should be understood that the order of steps described in the above embodiments is only an illustrative example. In actual implementation, the execution order of each step can be adjusted according to the specific circumstances, as long as the technical effect of the present invention can be achieved.

[0095] In some embodiments of the present invention, a compliance certificate is automatically generated upon successful verification. The compliance certificate includes model detection logs and proof of satisfaction of all temporal logic formulas. The compliance certificate can be submitted to security audit departments or regulatory agencies to demonstrate that the diagnostic workflow mathematically complies with all security specifications.

[0096] In some embodiments of the present invention, an SOVD protocol extension interface is also provided. Specifically, the following API interfaces are added: The first interface is POST / validation / workflow / verify, which is used to receive diagnostic workflow JSON and return the validation result, including whether it passes or fails and the path of the negative example.

[0097] The second interface is GET / validation / rules, which is used to return a list of compliance rules applicable to the current vehicle. Each rule includes a rule identifier, rule description, corresponding timing logic formula, and applicable ECU identifier.

[0098] The third interface is POST / validation / workflow / autofix, which is used to receive diagnostic workflow JSON and return the corrected workflow and incremental validation report.

[0099] The above interface can be registered as the SOVD service type WorkflowValidationService, and clients can obtain this capability through service discovery.

[0100] In this embodiment, the diagnostic workflow is abstracted into a state machine model, safety specifications are compiled into temporal logic formulas, and a model detector is used to automatically check whether the workflow meets all specifications. If not, counterexample paths are extracted and understandable explanations are generated. The workflow is automatically corrected based on these explanations, and incremental verification ensures the effectiveness of the corrections. The entire process forms a complete safety operation assurance mechanism from workflow input to compliant deployment, improving the efficiency and accuracy of compliance verification for the diagnostic workflow.

[0101] In some embodiments of the present invention, such as Figure 7 As shown, Figure 7 This is a schematic diagram of the formal verification engine's workflow. In step S103, the formal verification engine is used to verify whether the state machine model satisfies the temporal logic formula. This embodiment further refines the specific workflow of the verification engine in S103. The content regarding the implementation method of the model detector and the state space optimization method in S103 can be implemented in conjunction with this embodiment, specifically including the following processes: The formal verification engine loads the state transition system and the LTL rule set. The state transition system comes from the diagnostic workflow parsing results in step S102, and the LTL rule set comes from the set of temporal logic formulas obtained after the safety specification transformation in step S103. The verification engine treats the state transition system as the model to be verified and each rule in the LTL rule set as an attribute to be verified. The model detector traverses the state space of the state transition system, checking one by one whether each LTL rule is satisfied on all reachable paths in the state space.

[0102] If all LTL rules are satisfied on all reachable paths in the state space, the model detector outputs a validation pass result and generates a validation report. The validation report contains proofs of the satisfaction of all rules and records the complete result of this validation.

[0103] If at least one LTL rule is not satisfied on some reachable path, the model detector outputs a counterexample path and the identifier of the rule violated by that counterexample path. The counterexample path is the specific execution path from the initial state to the violating state, in the format S0→S1→S2→…→S n A sequence of states, where each state node contains the values ​​of all state variables for that state.

[0104] The verification report is a complete record of the entire verification process, including the verification time, the number of rules loaded, the verification result of each rule, and the final verification conclusion. When verification passes, the verification report also includes proof that all rules are satisfied; when verification fails, the verification report also includes the counterexample path and the corresponding violation rule ID.

[0105] In this way, the model detector automatically checks whether all reachable paths meet safety specifications by exhaustively searching the state space. It can discover boundary condition violations that are difficult to cover by manual review, thus improving the comprehensiveness and accuracy of compliance verification.

[0106] To better implement the formal verification-based vehicle diagnostic workflow assurance method in this invention embodiment, based on the formal verification-based vehicle diagnostic workflow assurance method, the corresponding method is as follows: Figure 8 As shown, this embodiment of the invention also provides a vehicle diagnostic workflow assurance device based on formal verification. The vehicle diagnostic workflow assurance device 800 based on formal verification includes: The instruction acquisition module 801 is used to acquire the diagnostic workflow, which includes multiple diagnostic operation instructions. The instruction parsing module 802 is used to parse the diagnostic workflow into a state machine model, wherein each diagnostic operation instruction is modeled as a state transition, and the state transition includes a precondition, an action, and a postcondition. The specification conversion module 803 is used to obtain the security specification, convert the security specification into a temporal logic formula, and use a formal verification engine to verify whether the state machine model satisfies the temporal logic formula, and obtain the verification result. The verification processing module 804 is used to perform diagnostic processing on the diagnostic workflow based on the verification results.

[0107] The formal verification-based vehicle diagnostic workflow assurance device 800 provided in the above embodiments can realize the technical solutions described in the above formal verification-based vehicle diagnostic workflow assurance method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above formal verification-based vehicle diagnostic workflow assurance method embodiments, which will not be repeated here.

[0108] like Figure 9 As shown, the present invention also provides an electronic device 900. The electronic device 900 includes a processor 901, a memory 902, a display 903, and a communication interface 904. Figure 9 Only some components of the electronic device 900 are shown, but it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0109] In some embodiments, processor 901 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 902 or process data, such as the formal verification-based vehicle diagnostic workflow assurance method of the present invention.

[0110] In some embodiments, processor 901 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 901 may be local or remote. In some embodiments, processor 901 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-cloud, etc., or any combination thereof.

[0111] In some embodiments, memory 902 may be an internal storage unit of electronic device 900, such as a hard disk or memory of electronic device 900. In other embodiments, memory 902 may also be an external storage device of electronic device 900, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 900.

[0112] Furthermore, the memory 902 may include both internal storage units of the electronic device 900 and external storage devices. The memory 902 is used to store application software and various types of data installed on the electronic device 900.

[0113] In some embodiments, display 903 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. Display 903 is used to display information from electronic device 900 and to display a visual user interface.

[0114] The communication interface 904 is used to enable data communication between the electronic device 900 and external devices. In some embodiments, the communication interface 904 can be a wired communication interface or a wireless communication interface, or any combination thereof. The wired communication interface includes, but is not limited to, a CAN interface, a LIN interface, an automotive Ethernet interface, an RS-232 interface, an RS-485 interface, a USB interface, or an Ethernet interface. The wireless communication interface includes, but is not limited to, a Wi-Fi interface, a Bluetooth interface, a ZigBee interface, a 4G communication interface, or a 5G communication interface.

[0115] Communication interface 904 is used to acquire diagnostic workflow and safety specifications, and output verification pass indications and / or corrected workflows for processor 901 to invoke when executing the formal verification-based vehicle diagnostic workflow assurance method. In one embodiment, when processor 901 executes the formal verification-based vehicle diagnostic workflow assurance program in memory 902, the following steps can be implemented: Obtain the diagnostic workflow, which contains multiple diagnostic operation instructions; The diagnostic workflow is parsed as a state machine model, wherein each diagnostic operation instruction is modeled as a state transition, and the state transition includes a precondition, an action, and a postcondition. Obtain the security specifications, convert the security specifications into temporal logic formulas, and use a formal verification engine to verify whether the state machine model satisfies the temporal logic formulas, and obtain the verification results; Based on the verification results, diagnostic processing is performed on the diagnostic workflow.

[0116] It should be understood that when the processor 901 executes the formal verification-based vehicle diagnostic workflow assurance program in the memory 902, in addition to the functions mentioned above, it can also perform other functions, as detailed in the description of the corresponding method embodiments above.

[0117] Furthermore, the embodiments of the present invention do not specifically limit the type of electronic device 900 mentioned. Electronic device 900 can be a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, laptop computer, or other portable electronic device. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic device can also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the present invention, electronic device 900 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0118] Accordingly, this application also provides a computer-readable storage medium for storing a computer-readable program or instruction. When the program or instruction is executed by a processor, it can implement the steps or functions of the formal verification-based vehicle diagnostic workflow assurance method provided in the above-described method embodiments.

[0119] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0120] The foregoing has provided a detailed description of the vehicle diagnostic workflow assurance method, apparatus, and electronic equipment based on formal verification provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for ensuring vehicle diagnostic workflow based on formal verification, characterized in that, include: Obtain the diagnostic workflow, which contains multiple diagnostic operation instructions; The diagnostic workflow is parsed as a state machine model, wherein each diagnostic operation instruction is modeled as a state transition, and the state transition includes a precondition, an action, and a postcondition. Obtain the security specifications, convert the security specifications into temporal logic formulas, and use a formal verification engine to verify whether the state machine model satisfies the temporal logic formulas, and obtain the verification results; Based on the verification results, diagnostic processing is performed on the diagnostic workflow.

2. The vehicle diagnostic workflow assurance method based on formal verification according to claim 1, characterized in that, The state machine model consists of multiple state nodes and state transitions connecting the state nodes. The state machine model includes state variables and the values ​​of the state variables at each state node. The state variables include at least one of vehicle speed, gear position, high voltage power-on state, safety unlock state, engine speed, and battery state of charge.

3. The vehicle diagnostic workflow assurance method based on formal verification according to claim 1, characterized in that, The security specification is converted into a timing logic formula, including: Obtain a structured rule description file, wherein the structured rule description file contains at least one rule, and each rule contains a rule type identifier and a rule condition expression; The type of the rule is determined based on the rule type identifier, and the type includes security constraint type, precondition constraint type, sequence constraint type, and response constraint type. Based on the rule type identifier and the rule condition expression, the rule is mapped to a corresponding type of time-series logic formula.

4. The vehicle diagnostic workflow assurance method based on formal verification according to claim 3, characterized in that, Mapping the rules to corresponding time-series logic formulas includes: The rules of the security constraint type are converted into a first type of temporal logic formula, which indicates that the first condition and the second condition are not both true at the same time. The rules of the pre-constraint type are converted into a second type of temporal logic formula, which means that the target pre-conditions must be met before the target diagnostic operation instruction is executed. The rules of the sequential constraint type are converted into a third type of temporal logic formula, which indicates that the first diagnostic operation instruction must be executed before the second diagnostic operation instruction is executed. The rules of the response constraint type are converted into a fourth type of time-series logic formula, which means that the response condition must be met within a preset time range after the trigger condition is met.

5. The vehicle diagnostic workflow assurance method based on formal verification according to any one of claims 1 to 4, characterized in that, Based on the verification results, diagnostic processing is performed on the diagnostic workflow, including: When the verification result is satisfactory, a verification pass indication is output; When the verification result is not satisfied, the counterexample path output by the formal verification engine is obtained, and violation explanation information is generated based on the counterexample path; Based on the violation explanation information, a correction operation is performed on the diagnostic workflow to obtain a corrected workflow, and incremental verification is performed on the corrected workflow. When the incremental verification passes, a verification pass indication is output, and the corrected workflow is deployed to the vehicle diagnostic execution terminal.

6. The vehicle diagnostic workflow assurance method based on formal verification according to claim 5, characterized in that, Based on the aforementioned counterexample path, violation explanation information is generated, including: Extract the state variable values ​​and workflow step identifiers corresponding to each state node from the counterexample path; Traverse the state nodes in the counterexample path and mark the violation step at the first state transition that violates the timing logic formula; Extract the preconditions, actual state variable values, and required state variable values ​​corresponding to the violation steps; The step identifier of the violation step, the rule identifier of the violation, the actual state variable value, and the required state variable value are filled into the preset explanation template to generate violation explanation information.

7. The vehicle diagnostic workflow assurance method based on formal verification according to claim 5, characterized in that, Based on the violation explanation information, perform corrective operations on the diagnostic workflow, including: The type of root cause of the violation is determined based on the violation explanation information; Based on the type of violation root cause, a corresponding correction template is matched from the correction template library, which contains at least one of the following correction templates: Insert a pre-check template to insert conditional check and diagnostic operation instructions before the violation step; Add a pre-routine template to insert a pre-routine call instruction before the violation step; Adjust the sequence template to swap the execution order of adjacent diagnostic operation instructions that violate dependencies; Add a status wait template to insert diagnostic operation instructions that loop through the status variable until the condition is met. The diagnostic workflow is corrected based on the matched correction template to obtain the corrected workflow.

8. The vehicle diagnostic workflow assurance method based on formal verification according to claim 5, characterized in that, Perform incremental verification on the revised workflow, including: Determine the location of the modification node corresponding to the correction operation in the diagnostic workflow; Based on the modified node position, the affected state subspace is determined from the state machine model, the affected state subspace containing state nodes from the modified node position to the endpoint of the diagnostic workflow; Using the previous state before the modified node position as the initial state, the affected state subspace is verified.

9. A vehicle diagnostic workflow assurance device based on formal verification, characterized in that, include: The instruction acquisition module is used to acquire the diagnostic workflow, which contains multiple diagnostic operation instructions. The instruction parsing module is used to parse the diagnostic workflow into a state machine model, wherein each diagnostic operation instruction is modeled as a state transition, and the state transition includes a precondition, an action, and a postcondition. The specification transformation module is used to obtain the security specification, convert the security specification into a temporal logic formula, and use a formal verification engine to verify whether the state machine model satisfies the temporal logic formula, and obtain the verification result. The verification processing module is used to perform diagnostic processing on the diagnostic workflow based on the verification results.

10. An electronic device, characterized in that, Includes communication interfaces, memory, and processor; The communication interface is used to obtain diagnostic workflows and safety specifications; The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the formal verification-based vehicle diagnostic workflow assurance method according to any one of claims 1 to 8.

Images