Vehicle diagnosis management method and device, electronic equipment and readable storage medium

Abstract

The invention relates to a vehicle diagnosis management method and device, electronic equipment and a readable storage medium, and belongs to the technical field of vehicle diagnosis. The method comprises the following steps: determining a diagnosis state and a diagnosis event in a vehicle diagnosis service; determining a state enumeration and trigger event based on the diagnosis state and the diagnosis service, and generating a corresponding state machine which comprises a diagnosis task state machine and a vehicle diagnosis state machine; performing event definition, state enumeration definition, condition setting and action setting on the state machine; controlling the vehicle diagnosis state machine to flow from an initial state to a diagnosis starting state through a trigger event, and persistently recording a diagnosis task and the change of the state of the diagnosis task by utilizing a MySQL (Structured Query Language) database; and the diagnosis state, the diagnosis event and the circulation in the vehicle diagnosis service are adjusted through the state machine, and the state machine is dynamically adjusted. According to the method and the device, the problem of low vehicle safety caused by disorder of a diagnosis process due to incapability of effectively processing complex state conversion in an existing state management mode is solved.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a vehicle diagnosis management method, device, electronic device and storable medium. Background Art

[0002] With the development of intelligent automobiles, Internet of Vehicles technology and remote diagnosis technology have become important directions for the development of the automobile industry. Internet of Vehicles technology uses wireless communication technology to connect vehicles to each other, vehicles to road facilities, and vehicles to the Internet, thereby providing a more intelligent driving experience and services. Remote diagnosis technology can remotely diagnose and repair vehicles through the network, greatly improving the efficiency and convenience of vehicle maintenance. COLA state machine is a lightweight, high-performance state machine framework open sourced by the Alibaba Cloud team to solve the control problem of state flow in business processes. It is based on stateless design, supports event-driven and distributed transactions, and is suitable for building complex and highly concurrent state machine models. At present, MQTT (Message Queuing Telemetry Transport) and DOIP (Diagnostic Communication over Internet Protocol) protocols are usually used to remotely diagnose faulty vehicles, which can complete the interaction of vehicle-cloud commands and data, thereby realizing remote fault diagnosis and repair of vehicles. However, due to the complexity of Internet of Vehicles and remote diagnosis technology, the existing state management methods often cannot effectively handle various complex states and state transitions, resulting in confusion and errors in the diagnosis process, affecting the accuracy of vehicle diagnosis and vehicle safety. This paper proposes a vehicle diagnosis management method based on the COLA state machine.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The present application provides a vehicle diagnostic management method, device, electronic device and storable medium to solve the above-mentioned technical problem of being unable to effectively handle various complex states and state transitions, resulting in confusion and errors in the diagnostic process.

[0005] According to one aspect of an embodiment of the present application, the present application provides a vehicle diagnostic management method, including: determining the diagnostic status and diagnostic events in a vehicle diagnostic service; determining a state enumeration and a trigger event based on the diagnostic status and the diagnostic service, and generating a corresponding state machine, the state machine including a diagnostic task state machine and a vehicle diagnostic state machine; performing event definition, state enumeration definition, condition setting and action setting for the state machine respectively; controlling the vehicle diagnostic state machine to flow from an initial state to a diagnostic on state through the trigger event, and using a MySQL database to persistently record changes in diagnostic tasks and their states; adjusting the diagnostic status, the diagnostic events and the flow relationship in the vehicle diagnostic service through the state machine, and dynamically adjusting the state machine.

[0006] Optionally, determining the diagnostic status and diagnostic service in the vehicle diagnostic service includes: obtaining the vehicle diagnostic service; extracting the diagnostic status in the vehicle diagnostic service according to service requirements; and dividing the vehicle diagnostic service into service according to the diagnostic process to obtain diagnostic events.

[0007] Optionally, the state enumeration and trigger event are determined based on the diagnostic state and the diagnostic service, and a corresponding state machine is generated. The state machine includes a diagnostic task state machine and a vehicle diagnostic state machine, including: determining the state enumeration according to the diagnostic state; identifying possible trigger events for each of the diagnostic states; generating corresponding diagnostic task state machines and vehicle diagnostic state machines based on the state enumeration and the trigger event; and determining state flow relationships, including external flow and internal flow.

[0008] Optionally, the event definition, state enumeration definition, condition setting and action setting for the state machine respectively include: event definition for the state machine according to the trigger event; event definition for the state machine according to the state enumeration; setting state flow conditions for each flow state of the state machine; and defining actions to be performed when the state flows.

[0009] Optionally, the trigger event includes a vehicle diagnostic status trigger event and a diagnostic task status trigger event; the status enumeration includes a vehicle diagnostic status enumeration and a diagnostic task status enumeration.

[0010] Optionally, the trigger event is used to control the vehicle diagnostic state machine to flow from the initial state to the diagnostic on state, and the MySQL database is used to persistently record the changes in the diagnostic tasks and their states, including: initializing the vehicle diagnostic state machine and the diagnostic task state machine, and setting the initial state; writing event trigger logic to trigger the corresponding trigger event when specific conditions are met; executing state transfer and calling corresponding actions according to the current diagnostic event and the current diagnostic state; persisting the new state information in the MySQL database during the state transfer; designing the database table structure to record the diagnostic task status and the vehicle diagnostic status through the database table structure.

[0011] Optionally, the diagnostic status, diagnostic events and flow relationships in the vehicle diagnostic service are adjusted through the state machine, and the state machine is dynamically adjusted, including: adding new diagnostic status, diagnostic events and flow relationships in real time according to changes in business needs; modifying the definitions of existing diagnostic status, diagnostic events and flow relationships to adapt to new business scenarios; using the configuration center to annotate the state machine and dynamically adjust the state machine; automatically refreshing the configuration of the state machine when the configuration changes.

[0012] According to another aspect of an embodiment of the present application, the present application provides a vehicle diagnostic management device, including: an identification module, used to identify diagnostic status and diagnostic events in vehicle diagnostic services; a definition module, used to determine state enumeration and trigger events based on the diagnostic status and diagnostic services, and generate a corresponding state machine, the state machine including a diagnostic task state machine and a vehicle diagnostic state machine; a state machine configuration module, used to perform event definition, state enumeration definition, condition setting and action setting for the state machine respectively; a state flow module, used to control the vehicle diagnostic state machine to flow from an initial state to a diagnostic start-up state through a trigger event, and use a MySQL database to persistently record changes in diagnostic tasks and their states; a state machine adjustment module, used to adjust the diagnostic status, diagnostic events and flow in the vehicle diagnostic services through the state machine, and dynamically adjust the state machine.

[0013] According to another aspect of an embodiment of the present application, the present application provides an electronic device, including a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, and the memory and the processor communicate through the communication bus and the communication interface, and is characterized in that the processor implements the instructions of the above method when executing the computer program.

[0014] According to another aspect of an embodiment of the present application, the present application further provides a readable storage medium storing program instructions, and when the program instructions are read and executed by a computing device, the computing device executes the above method.

[0015] The above technical solution provided by the embodiment of the present application has the following advantages compared with the related art:

[0016] This application makes the entire diagnostic process clearer and more orderly by clearly defining diagnostic states and diagnostic events, and building a state machine based on these definitions. The state machine can ensure that the correct actions are performed under specific conditions, thereby avoiding diagnostic errors caused by human errors or process confusion, and improving the accuracy and efficiency of diagnosis. The lightweight and highly scalable COLA state machine framework enables the system to easily cope with new diagnostic scenarios or requirements that may be added in the future. At the same time, its expression enhances the readability and maintainability of the code, allowing developers to more easily understand and modify the system and reduce maintenance costs. The state machine is allowed to be dynamically adjusted, including modifications to diagnostic states, diagnostic events, and flow logic. This flexibility enables the system to be continuously optimized based on actual operating conditions and feedback to adapt to changing diagnostic needs and environments. Through remote diagnostic technology, car owners can more conveniently obtain vehicle diagnostic results and maintenance recommendations without having to go to the repair station in person, which not only saves car owners' time and energy, but also improves user satisfaction and loyalty. The MySQL database is used to persistently record changes in diagnostic tasks and their states, providing a rich data source for subsequent data analysis and mining. By analyzing these data, we can further understand the key indicators such as the distribution of vehicle faults and diagnostic efficiency, providing strong support for optimizing the diagnostic process and improving service quality. The COLA state machine supports distributed transactions and event-driven, enabling the system to handle highly concurrent diagnostic requests, improving the overall performance and stability of the system. This feature is particularly important in the Internet of Vehicles environment, because the number of vehicles is large and widely distributed, requiring the system to have strong concurrent processing capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0019] Figure 1 A schematic diagram of a hardware environment of a vehicle diagnosis management method provided according to an embodiment of the present application;

[0020] Figure 2 A schematic diagram of a process flow of a vehicle diagnosis management method provided according to an embodiment of the present application;

[0021] Figure 3 A flowchart of remote diagnosis-diagnosis opening and closing provided according to an embodiment of the present application;

[0022] Figure 4 A flowchart of remote diagnosis-link establishment and routing activation provided according to an embodiment of the present application;

[0023] Figure 5 A flowchart of remote diagnosis-UDS command interaction provided according to an embodiment of the present application;

[0024] Figure 6 A flow chart of a vehicle diagnostic state machine provided according to an embodiment of the present application;

[0025] Figure 7 A flow chart of a diagnostic task state machine provided according to an embodiment of the present application;

[0026] Figure 8 A structural diagram of a vehicle diagnostic management device provided according to an embodiment of the present application;

[0027] Fig. 9 A schematic diagram of an optional electronic device structure provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0029] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application and have no specific meaning. Therefore, "module" and "component" can be used interchangeably.

[0030] In related technologies, due to the complexity of vehicle networking and remote diagnosis technology, existing state management methods are often unable to effectively handle various complex states and state transitions, resulting in confusion and errors in the diagnosis process, affecting the accuracy of vehicle diagnosis and the safety of the vehicle.

[0031] In order to solve the problems mentioned in the background technology, according to one aspect of an embodiment of the present application, an embodiment of a vehicle diagnosis management method is provided.

[0032] Optionally, in the embodiment of the present application, the above method can be applied to Figure 1In the hardware environment composed of the terminal 101 and the server 103 shown in FIG. Figure 1 As shown, the server 103 is connected to the terminal 101 via a network, and can be used to provide services for the terminal or a client installed on the terminal. A database 105 can be set on the server or independently of the server to provide data storage services for the server 103. The above-mentioned network includes but is not limited to: a wide area network, a metropolitan area network or a local area network, and the terminal 101 includes but is not limited to a PC, a mobile phone, a tablet computer, etc.

[0033] A vehicle diagnosis management method in the embodiment of the present application can be executed by the server 103, or can be executed by the server 103 and the terminal 101 together, such as Figure 2 As shown, the method may include the following steps:

[0034] S202, determining the diagnostic status and diagnostic events in the vehicle diagnostic service;

[0035] Specifically, determining the diagnostic status and diagnostic service in the vehicle diagnostic service includes:

[0036] Obtain vehicle diagnostic services;

[0037] Obtain vehicle diagnosis time; extract the diagnosis status in vehicle diagnosis business according to business needs;

[0038] The vehicle diagnosis business is divided into business categories according to the diagnosis process to obtain the diagnosis business.

[0039] In the remote diagnosis service, it mainly includes the normal process of the package service and the abnormal process, among which the flowchart of remote diagnosis-diagnosis opening and closing is as follows Figure 3 As shown, remote diagnosis-link establishment and routing activation are as follows Figure 4 As shown, the remote diagnosis-UDS command interaction is as follows Figure 5 As shown, remote diagnosis-status feedback is as follows Figure 6As shown. In this embodiment, the following main states are first defined to cover the entire diagnostic process: Initial state: the system has not started any diagnostic task and is in an idle state. To-be-activated state: a diagnostic request has been received, but a communication connection with the vehicle has not yet been established. Connection establishment: an attempt is being made to establish a communication connection with the vehicle. Connection established: a communication connection with the vehicle has been successfully established. Preparing for diagnostic tasks: after the connection is established, the system is ready to perform specific diagnostic tasks. Diagnosis execution: a UDS instruction or other diagnostic operation is being executed. Waiting for results: a diagnostic instruction has been sent, and the vehicle is waiting for a response result. Diagnosis completed: the diagnostic task has been completed, and the result processing or user confirmation is waiting. Diagnosis failed: an error was encountered during the diagnostic process, and the task was not successfully completed. Diagnosis ended: regardless of success or failure, the diagnostic task has officially ended, and the system returns to the idle state. Determine diagnostic events. The transitions between these states are usually triggered by specific events, including but not limited to: Receiving a diagnostic request: triggering a transition from the initial state to the to-be-activated state. Connection attempt: in the to-be-activated state, an attempt is made to establish a connection with the vehicle, triggering a transition to the connection establishment state. Connection success: After the connection is successfully established, the state transitions from connection establishment to connection established state. Connection failure: When the connection attempt fails, the state transitions from connection establishment back to the waiting to be activated state or the initial state. Start diagnostic task: In the connection established state, trigger the transition to the diagnostic task preparation state. Diagnostic task execution: After preparation is completed, start the diagnostic task and enter the diagnostic execution state. Receive result: Receive the diagnostic result from the vehicle and transition from waiting for result to the diagnosis completion or diagnosis failure state. Task completion: The diagnostic task is successfully completed, triggering the transition to the diagnosis completion state. Task failure: The diagnostic task fails for some reason, triggering the transition to the diagnosis failure state. End diagnosis: Regardless of success or failure, the user or the system automatically ends the diagnostic task and transitions from the diagnosis completion or diagnosis failure state to the diagnosis end state.

[0040] In the above embodiments, by clarifying the diagnostic status and diagnostic events in the vehicle diagnostic business, the entire diagnostic process is made clearer and more organized. By dividing the diagnostic process into business, the execution order and resource allocation of each link can be optimized, thereby improving the execution efficiency of the diagnostic task. At the same time, clear status and event definitions also help the system to quickly respond to and handle various situations and shorten the diagnostic cycle. A complete diagnostic process including normal processes and abnormal processes is defined, so that the system can fully cover various possible situations. When encountering abnormal situations, the system can handle them according to the predetermined process, avoiding problems such as system crashes or data loss caused by abnormal situations, and enhancing the robustness and reliability of the system. By recording and tracking changes in diagnostic status and events, the execution process of diagnostic tasks can be easily tracked, and problems can be quickly located, which can significantly improve maintenance efficiency and user satisfaction.

[0041] S204, determining state enumeration and triggering events based on the diagnostic state and the diagnostic service, and generating a corresponding state machine, the state machine including a diagnostic task state machine and a vehicle diagnostic state machine;

[0042] Specifically, based on the diagnostic state and the diagnostic service, the state enumeration and the triggering event are determined, and a corresponding state machine is generated. The state machine includes a diagnostic task state machine and a vehicle diagnostic state machine, including:

[0043] Determine the status enumeration based on the diagnostic status;

[0044] Identify possible triggering events for each diagnostic state;

[0045] Generate corresponding diagnostic task state machine and vehicle diagnostic state machine based on state enumeration and trigger events;

[0046] Determine the state flow relationship, including external flow and internal flow.

[0047] In this embodiment, according to the status sorted out by the remote diagnosis service, the state enumeration and trigger events are sorted out and a state machine is established. The state machine mainly includes a diagnostic task state machine and a vehicle diagnostic state machine. Among them, the diagnostic task state machine is as follows: Figure 7 As shown, the vehicle diagnostic state machine is as follows Figure 8 As shown in the figure. In the state machine, each state transition defines an external flow or an internal flow. The external flow usually involves external events (such as user requests, system notifications, etc.), while the internal flow may be triggered by the internal logic of the state machine (such as timeouts, retry mechanisms, etc.). For example, an external event triggers an external flow from IDLE to PENDING_ACTIVATION. Internal flows may include automatically retrying the connection when the connection fails, or marking the task as failed after a timeout while waiting for the result.

[0048] In the above embodiment, by abstracting the complex logic in the vehicle diagnosis business into a state machine and state enumeration, the system structure is made clearer and more modular. When the business requirements change, only the state enumeration, trigger event or state flow relationship needs to be adjusted without large-scale reconstruction of the entire system. The state machine ensures that the behavior of the system in different states is predictable and controllable by clearly defining the state flow relationship and trigger conditions, which helps to reduce problems such as system crashes or data inconsistencies caused by logical errors or abnormal situations, and enhances the robustness and stability of the system. By managing the state flow of diagnostic tasks and vehicle diagnosis through the state machine, the business processing process can be optimized and the processing efficiency can be improved. The state machine can automatically perform corresponding operations according to the current state and trigger events, reducing the possibility of manual intervention and misjudgment, thereby speeding up the business processing speed. The state machine can reflect the current status of the diagnostic task and vehicle diagnosis in real time and provide clear feedback to the user. The user can understand the execution progress and results of the task based on the feedback of the state machine, so as to make more accurate decisions and actions. In the remote diagnosis business, managing these scenarios and situations through the state machine can ensure that the system can process according to the predetermined logic and rules, avoiding confusion and errors caused by complex business logic. The state machine supports the definition of external and internal flows, allowing the system to flexibly respond to various external events and internal logic changes. The state machine records the complete execution process of diagnostic tasks and vehicle diagnosis, including information such as state transitions and trigger events. When a problem occurs in the system, you can quickly locate the problem and take appropriate solutions by viewing the execution log and state transition records of the state machine.

[0049] S206, respectively defining events, defining state enumerations, setting conditions, and setting actions for the state machine;

[0050] Specifically, based on the user attribute data, the state machine is respectively subjected to event definition, state enumeration definition, condition setting and action setting, including:

[0051] Define events for the state machine based on triggering events;

[0052] Define events for the state machine based on state enumeration;

[0053] Set state transition conditions for each flow state of the state machine;

[0054] Define the actions to be performed when the state changes.

[0055] More specifically, the events include vehicle diagnostic status trigger events and diagnostic task status trigger events; the status enumerations include vehicle diagnostic status enumerations and diagnostic task status enumerations.

[0056] In this embodiment, firstly, the events and enumerations for triggering the state flow of the state machine, the vehicle diagnostic state and the diagnostic task state, are defined, assuming that all state flows are unconditional (i.e., all conditions are met by default). The action setting usually includes the state change and the business logic processing related thereto, assuming that each action is a simple state change record. The state machine of this embodiment uses the COLA state machine framework.

[0057] In the above embodiments, new business needs or changes can be easily adapted through clear event definitions and state enumerations. When a new diagnostic task or vehicle diagnostic state appears, only new events or state enumerations need to be added to the system without large-scale reconstruction of the entire state machine. Clear state flow conditions and action settings make the system logic more intuitive and easy to understand, reducing the difficulty of subsequent maintenance and debugging. When a problem occurs, developers can quickly locate the relevant state or event and perform targeted repairs. Each state flow is accompanied by clear condition settings and action definitions, ensuring the accuracy of the system when processing user attribute data and executing corresponding business logic. Errors or exceptions caused by unclear logic or improper handling are avoided. The state machine design can handle complex business logic and state changes well. By defining multiple states and events and setting corresponding flow conditions and actions, the system can flexibly handle various complex business scenarios, such as multi-step vehicle diagnostic processes or diagnostic tasks of different priorities. By accurately controlling state flow and executing relevant actions in a timely manner, the system can provide users with a smoother and more efficient service experience. For example, during the vehicle diagnosis process, the system can automatically push the corresponding diagnostic report or prompt information to the user according to the current state. Using the standard COLA state machine framework for development makes the system easier to integrate and collaborate with other systems or components. At the same time, the standardized design also facilitates communication and collaboration among team members and improves development efficiency.

[0058] S208, controlling the vehicle diagnosis state machine to flow from the initial state to the diagnosis start state through the triggering event, and using the MySQL database to persistently record the diagnosis task and its state changes;

[0059] Specifically, the vehicle diagnostic state machine is controlled to flow from the initial state to the diagnostic start state by triggering events, and the MySQL database is used to persistently record the diagnostic tasks and their state changes, including:

[0060] Initialize the vehicle diagnostic state machine and the diagnostic task state machine, and set the initial state;

[0061] Write event trigger logic to trigger corresponding trigger events when specific conditions are met;

[0062] According to the current diagnostic event and current diagnostic status, execute the state flow and call the corresponding action;

[0063] When the state changes, the new state information is persisted in the MySQL database;

[0064] Design the database table structure and use it to record the diagnostic task status and vehicle diagnostic status.

[0065] In this embodiment, various states of vehicle diagnosis are first defined, such as NONE (initial state), ENABLED (diagnosis enabled), RUNNING (diagnosis in progress), COMPLETED (diagnosis completed), FAILED (diagnosis failed), etc. Then, events that can trigger state changes of the state machine are defined, such as ENABLE (enable diagnosis), START (start diagnosis), STOP (stop diagnosis), COMPLETE (complete diagnosis), FAIL (diagnosis failed), etc. Create a vehicle diagnosis state machine object and set its initial state to NONE. Integrate event trigger points in the business logic. For example, when the user clicks the "Start Diagnosis" button through the UI interface, the system will trigger a START event. Before triggering the event, the system should check whether the trigger conditions are currently met, such as whether the vehicle is online, whether there is enough power, etc. Once the conditions are met, the event is passed to the state machine for processing. After the state machine receives the event, it determines whether a state transition is required based on the current state and event type. If necessary, the current state of the state machine is updated, and any operations related to the new state are performed (such as starting the diagnosis process, sending notifications, etc.). Ensure that the state transition complies with the predefined business rules to avoid entering an invalid or inconsistent state. Design a database table for diagnostic tasks and their status, including fields such as task ID, vehicle ID, task name, start time, end time, current status, etc. When the state machine performs state transitions, persist the new state information to the database. This can be achieved by updating existing records or inserting new records, depending on business requirements and system design. During database operations, possible exceptions such as connection failures, SQL errors, etc. should be handled, and data integrity and consistency should be ensured.

[0066] In the above embodiment, the state flow of the state machine is controlled by event triggering, which can quickly respond to user operations, such as starting the diagnostic process immediately after clicking the "Start Diagnosis" button, reducing user waiting time and improving user experience. Before the state machine performs state transition, the system will check the triggering conditions to ensure that the state transition is performed only when the conditions are met. System anomalies or errors caused by improper state transitions are avoided, and the reliability and stability of the system are enhanced. By persisting the diagnostic task and its state changes in the MySQL database, the system can record the complete diagnostic process, including key information such as task ID, vehicle ID, task name, start time, end time, current status, etc. This provides strong support for subsequent data analysis, problem tracking and auditing. The state machine design can handle complex business logic and state changes, such as pause, continue, failure, etc. that may occur during the diagnostic process. By defining clear states and events, as well as corresponding actions, the system can flexibly respond to various business scenarios and ensure the smooth progress of the diagnostic process.

[0067] S210, adjusting the diagnostic state, diagnostic events and flow in the vehicle diagnostic service through the state machine, and dynamically adjusting the state machine.

[0068] Specifically, the diagnostic status, diagnostic events and flow in the vehicle diagnostic service are adjusted through the state machine, and the state machine is dynamically adjusted, including:

[0069] New diagnostic status, diagnostic events and flow relationships are added in real time according to changes in business needs.

[0070] Modify the definitions of existing diagnostic status, diagnostic events, and flow relationships to adapt to new business scenarios;

[0071] Use the configuration center to annotate the state machine and dynamically adjust the state machine;

[0072] Automatically refresh the state machine configuration when the configuration changes.

[0073] In this embodiment, in the vehicle diagnostic business, as business needs continue to change, new diagnostic states, diagnostic events, and the flow relationship between them need to be supplemented in real time. The configurable state machine design of this embodiment can easily add new states, events, and flow logic without large-scale reconstruction of the code. When the existing diagnostic state, diagnostic event, or flow relationship no longer meets the new business scenario, it is necessary to be able to easily modify these definitions. This can be achieved by editing the configuration file of the state machine or adjusting it using a graphical tool. The modified definition should be able to be seamlessly integrated into the existing business logic to ensure the continuity and stability of the system. In order to adjust the state machine configuration more flexibly, a configuration center (such as Nacos) can be used to manage the relevant configuration information of the state machine. By storing the definition of the state machine, the mapping relationship between the state and the event, etc. in the configuration center, centralized management and dynamic update of the configuration can be achieved. When the configuration changes, the system can automatically sense and refresh the configuration of the state machine, thereby achieving dynamic adjustment without restarting the service. Combined with the @RefreshScope annotation or other similar mechanisms in frameworks such as SpringCloud, dynamic refresh of the state machine configuration can be achieved. When the state machine configuration in the configuration center changes, the system automatically reloads these configurations and updates them to the currently running state machine instance. In this way, the behavior of the state machine can be adjusted as needed without interrupting the service even during business operation. Use the flexibility and extensibility of the COLA state machine framework to supplement new diagnostic states, diagnostic events, and flow relationships. Taking the TCP link closure event as an example, it shows how to define the flow path from multiple existing states to the TCP link closure state through a state machine builder (such as builder.externalTransitions()). This declarative approach not only simplifies the complexity of the state machine configuration, but also improves the readability and maintainability of the system.

[0074] In the above embodiments, as business needs change, new diagnostic states, diagnostic events and flow relationships can be added in real time, or existing definitions can be modified to adapt to new business scenarios. This enables the system to respond quickly to market changes and customer needs, and improves the flexibility and adaptability of the system. Through the configurable state machine design, states, events and flow logic can be easily added, modified or deleted without large-scale reconstruction of the code. This greatly reduces the maintenance cost of the system and improves development efficiency. The use of the configuration center enables the configuration information of the state machine to be centrally managed and dynamically updated. When the system needs to expand new functions or business scenarios, it only needs to update the corresponding configuration information in the configuration center, and the system can automatically perceive and apply these changes without additional development work. This scalability enables the system to easily cope with future business growth and changes. In the process of dynamically adjusting the state machine configuration, the system can automatically refresh the configuration and update it to the currently running state machine instance, ensuring the continuity and stability of the system. Even if the configuration is adjusted during business operation, it will not affect the normal operation of the system, avoiding problems such as service interruption or data loss caused by configuration changes. By dynamically adjusting the diagnostic status, diagnostic events and flows in the vehicle diagnostic business, the system can more accurately reflect the actual status and diagnostic process of the vehicle, provide users with more accurate and timely information feedback, help improve user satisfaction and trust, and enhance user experience.

[0075] According to another aspect of the embodiment of the present application, Figure 8 As shown, the present application provides a vehicle diagnosis management device, comprising:

[0076] Identification module 301, used to identify the diagnosis state and diagnosis event in the vehicle diagnosis service;

[0077] A definition module 303 is used to determine state enumeration and trigger events based on diagnostic states and diagnostic services, and generate corresponding state machines, the state machines including diagnostic task state machines and vehicle diagnostic state machines;

[0078] The state machine configuration module 305 is used to define events, state enumerations, conditions and actions for the state machine;

[0079] The state transfer module 307 is used to control the vehicle diagnosis state machine to transfer from the initial state to the diagnosis start state through a trigger event, and to use the MySQL database to persistently record the changes of the diagnosis tasks and their states;

[0080] The state machine adjustment module 309 is used to adjust the diagnostic state, diagnostic events and flow in the vehicle diagnostic service through the state machine, and dynamically adjust the state machine.

[0081] It should be noted that the identification module 301 in this embodiment can be used to execute step S202 in the embodiment of the present application, the definition module 303 in this embodiment can be used to execute step S204 in the embodiment of the present application, the state machine configuration module 305 in this embodiment can be used to execute step S206 in the embodiment of the present application, the state flow module 307 in this embodiment can be used to execute step S208 in the embodiment of the present application, and the state machine adjustment module 309 in this embodiment can be used to execute step S210 in the embodiment of the present application.

[0082] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. It should be noted that the above modules as part of the device can be run in Figure 1 In the hardware environment shown, it can be implemented by software or by hardware.

[0083] According to another aspect of the embodiments of the present application, the present application provides an electronic device, such as Fig. 9 As shown, it includes a memory 401, a processor 403, a communication interface 405 and a communication bus 407. The memory 401 stores a computer program that can be run on the processor 403. The memory 401 and the processor 403 communicate through the communication interface 405 and the communication bus 407. When the processor 403 executes the computer program, the steps of the above method are implemented.

[0084] The memory and processor in the above electronic device communicate through the communication bus and the communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0085] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0086] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0087] According to another aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps of any of the above embodiments.

[0088] Optionally, in an embodiment of the present application, the computer-readable medium is configured to store program codes for the processor to execute the following steps:

[0089] Step S202, determining the diagnostic status and diagnostic events in the vehicle diagnostic service;

[0090] Step S204, determining state enumeration and triggering events based on the diagnostic state and diagnostic service, and generating a corresponding state machine, the state machine including a diagnostic task state machine and a vehicle diagnostic state machine;

[0091] Step S206, respectively performing event definition, state enumeration definition, condition setting and action setting for the state machine;

[0092] Step S208, controlling the vehicle diagnosis state machine to flow from the initial state to the diagnosis start state through the triggering event, and using the MySQL database to persistently record the diagnosis task and its state changes;

[0093] Step S210: adjusting the diagnostic state, diagnostic events and flow in the vehicle diagnostic service through the state machine, and dynamically adjusting the state machine.

[0094] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0095] When the embodiments of the present application are specifically implemented, reference may be made to the above-mentioned embodiments, which have corresponding technical effects.

[0096] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of the present application, or a combination thereof.

[0097] For software implementation, the technology of this article can be implemented by a unit that performs the functions of this article. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

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

[0099] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0100] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0102] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0103] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk. It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, article or device. Without more constraints, an element defined by the phrase "comprising a ..." does not exclude the existence of other identical elements in the process, method, article or apparatus comprising the element.

[0104] The above is only a specific implementation of the present application, so that those skilled in the art can understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest range consistent with the principles and novel features applied for herein.

Claims

1. A vehicle diagnosis management method, characterized in that: include: Determine diagnostic status and diagnostic events in vehicle diagnostic services; Determine state enumeration and trigger events based on the diagnostic state and the diagnostic service, and generate a corresponding state machine, the state machine including a diagnostic task state machine and a vehicle diagnostic state machine; Respectively performing event definition, state enumeration definition, condition setting and action setting for the state machine; The trigger event controls the vehicle diagnostic state machine to flow from the initial state to the diagnostic start state, and uses the MySQL database to persistently record the diagnostic tasks and their state changes; The diagnostic state, the diagnostic event and the flow relationship in the vehicle diagnostic service are adjusted through the state machine, and the state machine is dynamically adjusted.

2. The vehicle diagnosis management method according to claim 1, characterized in that: The determining of the diagnostic state and the diagnostic service in the vehicle diagnostic service includes: Obtain vehicle diagnostic services; Extracting the diagnostic status in the vehicle diagnostic service according to the service requirements; The vehicle diagnostic service is divided into service categories according to the diagnostic process to obtain diagnostic events.

3. The vehicle diagnosis management method according to claim 1, characterized in that: The state enumeration and triggering event are determined based on the diagnostic state and the diagnostic service, and a corresponding state machine is generated, wherein the state machine includes a diagnostic task state machine and a vehicle diagnostic state machine, including: determining a state enumeration according to the diagnostic state; identifying possible triggering events for each of said diagnostic states; Generate a corresponding diagnostic task state machine and a vehicle diagnostic state machine based on the state enumeration and the trigger event; Determine the state flow relationship, including external flow and internal flow.

4. The vehicle diagnosis management method according to claim 1, characterized in that: The respectively performing event definition, state enumeration definition, condition setting and action setting on the state machine includes: Performing event definition on the state machine according to the trigger event; Defining events for the state machine according to the state enumeration; Setting a state transition condition for each transition state of the state machine; Define the actions to be performed when the state changes.

5. The vehicle diagnosis management method according to claim 4, characterized in that: The trigger events include vehicle diagnostic status trigger events and diagnostic task status trigger events; the status enumerations include vehicle diagnostic status enumerations and diagnostic task status enumerations.

6. The vehicle diagnosis management method according to claim 1, characterized in that: The trigger event is used to control the vehicle diagnostic state machine to flow from the initial state to the diagnostic start state, and the MySQL database is used to persistently record the diagnostic task and its state changes, including: Initializing the vehicle diagnostic state machine and the diagnostic task state machine, and setting an initial state; Write event trigger logic to trigger corresponding trigger events when specific conditions are met; According to the current diagnostic event and current diagnostic status, execute the state flow and call the corresponding action; When the state changes, the new state information is persisted in the MySQL database; Design the database table structure and use it to record the diagnostic task status and vehicle diagnostic status.

7. The vehicle diagnosis management method according to claim 1, characterized in that: The step of adjusting the diagnostic state, the diagnostic event, and the flow relationship in the vehicle diagnostic service through the state machine and dynamically adjusting the state machine includes: Add new diagnostic status, diagnostic events and flow relationships in real time according to changes in business needs; Modify the definitions of existing diagnostic status, diagnostic events, and flow relationships to adapt to new business scenarios; Use the configuration center to annotate the state machine and dynamically adjust the state machine; The configuration of the state machine is automatically refreshed when the configuration changes.

8. A vehicle diagnosis management device, applicable to the vehicle diagnosis management method according to any one of claims 1 to 7, characterized in that: include: The attribute acquisition module is used to obtain the user attribute data, vehicle attribute data and event attribute data corresponding to each vehicle model; An identification module, used to identify the diagnostic status and diagnostic events in the vehicle diagnostic service; A definition module is used to determine state enumeration and trigger events based on diagnostic status and diagnostic services, and generate corresponding state machines, including diagnostic task state machines and vehicle diagnostic state machines; The state machine configuration module is used to define events, state enumerations, conditions and actions for the state machine; The state transfer module is used to control the vehicle diagnostic state machine from the initial state to the diagnostic start state through triggering events, and use the MySQL database to persistently record the diagnostic tasks and their state changes; The state machine adjustment module is used to adjust the diagnostic status, diagnostic events and flow in the vehicle diagnostic business through the state machine, and dynamically adjust the state machine.

9. An electronic device, comprising a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, and the memory and the processor communicate through the communication bus and the communication interface, characterized in that: When the processor executes the computer program, it implements the instructions of any one of the methods 1-7 above.

10. A readable storage medium storing program instructions, which, when read and executed by a computing device, causes the computing device to execute the method according to any one of claims 1 to 7.

Images